Fehler nach NewPrinterPage()

[Dieter]

Hallo zusammen!

Ich habe mit PB 5.31 64Bit unter Mac OSX 10.10 ein anscheinend alt bekanntes Problem:

Beim Druck der ersten Seite ist alles perfekt. Aber nachdem ich einen NewPrinterPage()
ausgeführt habe, wird bei jedem DrawText() nur der Anfangsbuchstabe gedruckt. Auf
allen Folgeseiten!

Hier in diesem Forum wurde der Fehler 2006 schon mal erwähnt, leider ohne Lösung.
Jemand meinte dass der Fehler nur auftritt, wenn Unicode eingeschalten ist. Unicode
kann ich aber nicht aussschalten, da ich Verzeichnisse meine Festplatte scanne usw.
und wenn in Datei- oder Verzeichnisnamen Umlaute usw. vorkommen, muss ich Unicode
verwenden.

Hat hierfür inzwischen jemand einen Lösung?

[Vera]

Hallo Dieter,

nur ein kleiner Tip: im englischen Forum gibt es eine Seite mit gesammelten Lösungen speziell zu MAC, und auch (weiter unten auf der Seite) eine Sammlung von Crossplattform-Lösungen.
Da könntest Du vielleicht gelegentlich fündig werden: Carbon API list for Mac

Gruß ~ Vera

[Dieter]

Hallo Vera,

vielen Dank für die Info. Habe schon mal drüber geschaut, allerdings noch nichts gefunden.

Parallel dazu habe ich mal Unicode im Compiler ausgeschalten und siehe da, auch auf der zweiten
Seite wird alles gedruckt. ABER die Umlaute kann ich dann vergessen. Ist also doch keine Lösung.
Leider macht die 32Bit-Version da keinen Unterschied, habe ich eben probiert.
Also dann muss ich halt weitersuchen ...

Gruß
Dieter

[Vera]

vielen Dank für die Info. Habe schon mal drüber geschaut, allerdings noch nichts gefunden.

gern geschehen ... es kommen bestimmt noch Gelegenheiten

Wenn es zunächst nur um den Ausdruck geht, dann könnte folgendes ja zunächst ausreichen, im normal-Modus die String-Pfade von UTF-8 (lesen) nach ASCII (schreiben) zu wandeln.
Probier doch mal, ob diese Procedure bei Dir läuft:

Code: Alles auswählen

Procedure.s UTF8ToAscii(UTF8.s)          ;converts UTF8 to Ascii. Output as String
  Protected *mem     = AllocateMemory(StringByteLength(UTF8, #PB_UTF8) + 1)
  Protected *len     = PokeS(*mem, UTF8, -1,  #PB_Ascii)
  Protected.s SAscii = PeekS(*mem, -1, #PB_UTF8)
  FreeMemory(*mem)
  ProcedureReturn SAscii
EndProcedure


; hier direkten Pfad angeben oder unterhalb den PathRequester nehmen

Verzeichnis$ = "/home/your/target/folder/"


If OpenWindow(0, 0, 0, 316, 216, "StringGadget Flags", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  EditorGadget(0, 8,  8, 300, 200)

  ; Verzeichnis$=PathRequester("Verzeichnis Wählen:",Verzeichnis$)

  If Verzeichnis$ <> ""
    If ExamineDirectory(0, Verzeichnis$, "*.*")
      While NextDirectoryEntry(0)
        If DirectoryEntryType(0) = #PB_DirectoryEntry_File


          CompilerIf #PB_Compiler_Unicode
          AddGadgetItem(0, -1, DirectoryEntryName(0))
          Debug DirectoryEntryName(0)
          
          CompilerElse
          string.s = DirectoryEntryName(0)   ; path string is UTF8
          string   = UTF8ToAscii(string.s)
          
          AddGadgetItem(0, -1, string )
          Debug string
          CompilerEndIf


        EndIf
      Wend
      FinishDirectory(0)
    EndIf
  EndIf


  Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf

(CompilerIf hab ich rein gemacht, damit man einfacher über Kreuz testen könnte)

Ein Auslesen und Schreiben von Dateien, sollte ähnlich funktionieren können.

Gruß ~ Vera

[Shardik]

Beim Druck der ersten Seite ist alles perfekt. Aber nachdem ich einen NewPrinterPage()
ausgeführt habe, wird bei jedem DrawText() nur der Anfangsbuchstabe gedruckt. Auf
allen Folgeseiten!

Der Text in der DrawText()-Funktion muß im Unicode-Modus ins ASCII-Format umgewandelt werden, damit der Ausdruck der ersten und zweiten Seite sowohl im ASCII- als auch im Unicode-Modus funktioniert und Umlaute korrekt ausgedruckt werden. Dies ist anscheinend ein Fehler in der NewPrinterPage()-Funktion von PureBasic, weil dieses Problem in der Tat erst bei der zweiten Seite auftritt!

Ich habe daher das Beispiel aus der Hilfe zu NewPrinterPage() einmal entsprechend abgewandelt und unter MacOS X 10.6.8 (Snow Leopard) mit PB 5.31 x86 und x64 und im ASCII- und Unicode-Modus erfolgreich getestet:

Code: Alles auswählen

Define ASCIIText.S
Define Text.S

LoadFont(0, "Arial", 80)

If PrintRequester()
  If StartPrinting("Zwei Blätter")
    If StartDrawing(PrinterOutput())
      DrawingMode(#PB_2DDrawing_Transparent)
      DrawingFont(FontID(0))

      DrawText(100, 100, "Seite 1 mit ÄÖÜäöüß")

      ; Dem Drucker sagen, dass eine neue Seite begonnen wird
      NewPrinterPage()

      Text = "Seite 2 mit ÄÖÜäöüß"

      CompilerIf #PB_Compiler_Unicode
        ASCIIText = Space(StringByteLength(Text, #PB_Ascii) / 2)
        PokeS(@ASCIIText, Text, -1, #PB_Ascii)
      CompilerElse
        ASCIIText = Text
      CompilerEndIf  
    
      DrawingFont(FontID(0))
      DrawText(100, 100, ASCIIText, RGB(0, 0, 0))
      
      StopDrawing()
    EndIf
    
    StopPrinting()
  EndIf
EndIf

Update 1: #PB_Unicode in #PB_Compiler_Unicode abgeändert. Danke Sicro für den Hinweis auf den Fehler!
Update 2: Länge des durch Space() angelegten ASCII-Strings im Unicode-Modus durch 2 dividiert, um nicht unnötigerweise die doppelte Menge an Speicherplatz zu allokieren. Danke Sicro für Deine genaue Analyse und Dein anschauliches Beispielprogramm!

[ts-soft]

@Shardik

Ist aber sehr gefährlich, was Du da machst

[Sicro]

Code: Alles auswählen

CompilerIf #PB_Unicode
        ASCIIText = Space(StringByteLength(Text, #PB_Ascii))

#PB_Compiler_Unicode muss hier stehen.

Eigentlich nicht tragisch, aber Space() erzeugt hier doppelten Buffer, weil das Leerzeichen im Unicode zwei Bytes benötigt. Siehe folgenden Code:

Code: Alles auswählen

Text.s = Space(1)
Debug StringByteLength(Text, #PB_Ascii)   ; Ausgabe: 1
Debug StringByteLength(Text, #PB_Unicode) ; Ausgabe: 2

[ts-soft]

ASCIIText.s mit ASCII Text vom StringManager im Unicode-Modus verwalten lassen, halte ich
auf jeden Falle für sehr leichtsinnig. Sofortiger Aufruf von DrawText, ohne weitere Stringfunktion,
läßt dies zwar Funktionieren, aber ...

[Dieter]

Ich bekomme die Umlaute in Datei- und Verzeichnisnamen nur wenn ich den Compiler auf Unicode stelle. Eine Konvertierung
nach ASCII kommt da anscheinend immer zu spät und ich erhalte statt der Umlaute nur Fragezeichen.

So wie es aussieht erwartet TextDraw() trotz Unicode-Einstellung ab der zweiten Seite einen ASCII-codierten String und bricht
beim ersten 0-Byte des druckenden Strings ab.

Nachdem ich alle Vorschläge ausprobiert habe und auch die eine oder andere Modifikation am Code nicht den erhofften Erfolg
gebracht hat, kam mir eine ganz andere Idee

Ich habe einfach:

Code: Alles auswählen

NewPrinterPage()

durch

Code: Alles auswählen

NewPrinterPage()
StopDrawing()
StartDrawing(PrinterOutput())

ersetzt.

Ist vielleicht nicht ganz im Sinne des Erfinders, aber es funktioniert! Und die Seiten bleiben auch zusammen in einem Druckauftrag
bzw. PDF-Datei.

Gruß
Dieter

[Shardik]

#PB_Compiler_Unicode muss hier stehen.

Eigentlich nicht tragisch, aber Space() erzeugt hier doppelten Buffer, weil das Leerzeichen im Unicode zwei Bytes benötigt.

Danke Sicro, Du hast natürlich recht. Leider ist mir dies peinlicherweise nicht zum ersten Mal passiert, ich bin sozusagen ein "Wiederholungstäter"... Ich habe meinen Beispiel-Code entsprechend abgeändert.

ASCIIText.s mit ASCII Text vom StringManager im Unicode-Modus verwalten lassen, halte ich auf jeden Falle für sehr leichtsinnig. Sofortiger Aufruf von DrawText, ohne weitere Stringfunktion, läßt dies zwar Funktionieren, aber ...

Thomas, leider scheint bei mir jemand auf der Leitung zu stehen, aber ich verstehe leider nicht, was daran auszusetzen ist. Ich wäre Dir dankbar, wenn Du mir dies erklären könntest, da ich diese und ähnliche Lösungen (auch in vielen Workarounds im englischen Forum) schon oft verwendet habe und mich bisher nie jemand auf ein Problem damit aufmerksam gemacht hat. Wenn ich die Problematik verstehe, werde ich gerne meine alten und zukünftigen Workarounds entsprechend anpassen...

Ich bekomme die Umlaute in Datei- und Verzeichnisnamen nur wenn ich den Compiler auf Unicode stelle. Eine Konvertierung nach ASCII kommt da anscheinend immer zu spät und ich erhalte statt der Umlaute nur Fragezeichen.

Dies ist ja ein Problem, das mit anderen PureBasic-Funktionen auftritt. Wenn Du ein kleines Code-Beispiel zeigen könntest, dann könnte ich Dir wahrscheinlich auch weiterhelfen...

So wie es aussieht erwartet TextDraw() trotz Unicode-Einstellung ab der zweiten Seite einen ASCII-codierten String und bricht beim ersten 0-Byte des druckenden Strings ab.

Nachdem ich alle Vorschläge ausprobiert habe und auch die eine oder andere Modifikation am Code nicht den erhofften Erfolg gebracht hat, kam mir eine ganz andere Idee

Hattest Du auch mein Code-Beispiel ausprobiert? Wie angemerkt, hatte ich es unter MacOS X 10.6.8 (Snow Leopard) x86 und x64 im ASCII- und Unicode-Modus getestet. Leider kann ich es derzeit noch nicht unter dem neuen MacOS X 10.10 (Yosemite) testen, da ich dieses noch nicht heruntergeladen habe. Mein Beispiel sollte trotz des kleinen Fehlers mit #PB_Unicode statt #PB_Compiler_Unicode auch unter Yosemite korrekt funktioniert haben...

Ich habe einfach:

Code: Alles auswählen

NewPrinterPage()

durch

Code: Alles auswählen

NewPrinterPage()
StopDrawing()
StartDrawing(PrinterOutput())

ersetzt.

Ist vielleicht nicht ganz im Sinne des Erfinders, aber es funktioniert! Und die Seiten bleiben auch zusammen in einem Druckauftrag
bzw. PDF-Datei.

Danke für die von Dir gefundene Lösung, die natürlich auch eine Möglichkeit darstellt. Trotzdem sollte natürlich der offensichtliche Fehler in PureBasic behoben werden. Wenn keiner diesen Fehler im englischen Forum meldet, werde ich dies erledigen.