[GastForen PrePress allgemein Typographie Private Use Area

  • Suche
  • Hilfe
  • Lesezeichen
  • Benutzerliste
Themen
Beiträge
Moderatoren
Letzter Beitrag

Private Use Area

Martin Fischer
Beiträge gesamt: 12783

7. Feb 2008, 11:44
Beitrag # 1 von 11
Bewertung:
(5689 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
In http://www.hilfdirselbst.ch/...i?post=335451#335451 wird ein Problem diskutiert, was vielleicht auch für dieses Forum von Interesse ist:

Was darf eine Anwendung mit Zeichen in der Private Use Area anstellen?

Darf eine Anwendung die Repräsentation dieser Zeichen ignorieren und beliebig anders umsetzen oder ist die im Font definierte Belegung verbindlich?
Darf eine Anwendung ein in Unicode definiertes Zeichen (z.B. geschütztes festes Leerzeichen) anders umsetzen (hier in InDesign CS3: geschütztes variables Leerzeichen).
Anderes Beispiel: In InDesign CS3 wird das 'schmale geschützte Leerzeichen' als Ersatz für das 'geschützte feste Leerzeichen' verwendet (http://www.hilfdirselbst.ch/..._P303284.html#303284).

Mich (und wahrscheinlich auch andere) würde die Meinung der Typographie-Experten interessieren.

(Dieser Beitrag wurde von Martin Fischer am 7. Feb 2008, 11:45 geändert)
X

Private Use Area

typografie.info
Beiträge gesamt: 403

7. Feb 2008, 12:05
Beitrag # 2 von 11
Beitrag ID: #335524
Bewertung:
(5673 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Antwort auf [ Martin Fischer ] Darf eine Anwendung die Repräsentation dieser Zeichen ignorieren und beliebig anders umsetzen ...?


Nö. Aber mir ist auch keine Anwendung bekannt, die das machen würde.
Warum auch? Da die Zeichen der PUA nicht standardisiert sind, weiß die Anwendung sowieso nicht, welche Zeichen da hinterlegt sind. Es nimmt den Unicode, holt das Zeichen in diesem Slot und zeigt es an. Wo soll da ein Problem bestehen?
(In dem verlinkten Thread scheint einfach ziemlich viel durcheinander gebracht worden zu sein.)

Ralf


als Antwort auf: [#335516]

Private Use Area

Martin Fischer
Beiträge gesamt: 12783

7. Feb 2008, 12:26
Beitrag # 3 von 11
Beitrag ID: #335530
Bewertung:
(5661 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Ralf,

Antwort auf [ typografie.info ] In dem verlinkten Thread scheint einfach ziemlich viel durcheinander gebracht worden zu sein.


In dem verlinkten Thread wurde dargestellt, daß ein Zeichen <F8FF>, ausgezeichnet mit der WingDings in InDesign CS2 als Pfeil nach rechts dargestellt wird und in InDesign CS3 als ein Zeichen ohne Belegung (Apfel mit rosa Unterlegung).
Das gewünschte Zeichen kann in CS3 als <F0F0> eingefügt werden.
Dieses Zeichen, <F0F0>, hat in CS2 mit diesem Font keine Belegung und wird als Rechteck mit rosa Unterlegung dargestellt.

Also: Die korrekte Darstellung des gewünschten Zeichens (Pfeil nach rechts) in einer bestimmten Schrift ist von der Version des verwendeten Programms (InDesign CS2 oder CS3) abhängig. InDesign CS2 und InDesign CS3 "scheinen" das Zeichen unterschiedlich zu belegen, wobei die Belegung in CS3 nicht mehr der Belegung im Font entspricht.

Ein ähnliches Phänomen konnte zwischen CS2 und CS3 mit dem geschützten festen Wortzwischenraum (U+00A0) und dem schmalen geschützten festen Wortzwischenraum (U+202F) festgestellt werden.


als Antwort auf: [#335524]

Private Use Area

typografie.info
Beiträge gesamt: 403

7. Feb 2008, 13:46
Beitrag # 4 von 11
Beitrag ID: #335550
Bewertung:
(5627 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Kann den Fehler nachvollziehen. Melde mich, wenn ich was herausbekommen habe.

Ralf


als Antwort auf: [#335530]

Private Use Area

xpressio
Beiträge gesamt: 1584

7. Feb 2008, 14:19
Beitrag # 5 von 11
Beitrag ID: #335557
Bewertung:
(5619 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Martin,

es gibt mehrere unterschiedliche Wingdings-Fonts – in keinem findet sich jedoch ein Zeichen mit dem Unicode *F8FF*. Der offene Pfeil nach rechts (»bolt at right«) hat die Codierung *F0F0*, sodass die Darstellung in CS3 der Codierung entspricht.

So wie sich mir das darstellt, handelt es sich in CS2 um einen Bug, der in CS3 bereinigt wurde.

Ähnlich könnte es sich auch mit den Wortzwischenräumen verhalten. Das kann ich jedoch z.Zt. nicht überprüfen, da sich QXP hier anders verhält als ID.

*F8FF* ist für die Belegung des Apfels reserviert.


als Antwort auf: [#335530]
(Dieser Beitrag wurde von xpressio am 7. Feb 2008, 14:33 geändert)

Private Use Area

Martin Fischer
Beiträge gesamt: 12783

7. Feb 2008, 15:01
Beitrag # 6 von 11
Beitrag ID: #335579
Bewertung:
(5603 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Albert,

Antwort auf: Der offene Pfeil nach rechts (»bolt at right«) hat die Codierung *F0F0*, sodass die Darstellung in CS3 der Codierung entspricht.

So wie sich mir das darstellt, handelt es sich in CS2 um einen Bug, der in CS3 bereinigt wurde.


Stimmt (s. Screenshot).
Danke für die Info.

Antwort auf: Ähnlich könnte es sich auch mit den Wortzwischenräumen verhalten.


Ich nehme an, hier ist es gerade andersherum.
Möglicherweise wurde oft beklagt, daß der geschützte Wortzwischenraum fest und nicht variabel ist. Und so kam es zu der genannten Lösung.
Oder aber die Info-Palette stellt hier die falsche Information bzgl. dem Unicode-Wert zur Verfügung. Letzterer entspricht auch dem Wert, der per Script ermittelt werden kann.

Ein aus Word importierter fester geschützter Wortzwischenraum kommt in ID CS3 als variabler geschützer Wortzwischenraum mit U+00A0 an.
In InDesign CS2 kommt er als fester geschützter Wortzwischenraum mit U+00A0 an.

Dasselbe Zeichen ist demnach in InDesign CS2 ein fester geschützter Wortzwischenraum und in CS3 ein variabler.


als Antwort auf: [#335557]
Anhang:
F0F0.jpg (3.71 KB)

Private Use Area

xpressio
Beiträge gesamt: 1584

7. Feb 2008, 16:55
Beitrag # 7 von 11
Beitrag ID: #335623
Bewertung:
(5582 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Martin,

in QXP hat das Halbgeviert-Leerzeichen den Wert *00A0*. Importiert man eine Word-Datei mit einem geschützten Leerzeichen in QXP, kommt es auch hier als geschütztes Standard-Leerzeichen (No-Break Space) an, ebenso in CS3.

Es gibt keinen Unicodewert für einen *flexiblen* Wortzwischenraum. Das ist eine Spezialität der Layoutprogramme. Drum haben die Entwickler wohl hier auch ihre Probleme.

Der schmale geschützte WZR *202F* lässt sich zwar als Unicode in QXP eingeben, ist aber hier nicht definiert, kann also als Sonderzeichen nicht dargestellt werden – und entspricht etwa einem Zweidrittelgeviert, also ganz und gar nicht narrow, eher narrisch.

Auch bei der Konvertierung von ID-Dateien in QXP-Dateien werden Wortzwischenräume unterschiedlich interpretiert.

Zur Erläuterung: http://de.wikipedia.org/wiki/Leerzeichen.

Bugreport: Ich bin definitiv nicht »Albert« ;-)


als Antwort auf: [#335579]

Private Use Area

Martin Fischer
Beiträge gesamt: 12783

7. Feb 2008, 17:24
Beitrag # 8 von 11
Beitrag ID: #335631
Bewertung:
(5572 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo xpressio,

Antwort auf: Es gibt keinen Unicodewert für einen *flexiblen* Wortzwischenraum. Das ist eine Spezialität der Layoutprogramme. Drum haben die Entwickler wohl hier auch ihre Probleme.


Deswegen auch meine Vermutung hinsichtlich der Beweggründe für die Umdefinition des "Verhaltens" des festen geschützten Wortzwischenraums in InDesign CS3.

Antwort auf: entspricht etwa einem Zweidrittelgeviert, also ganz und gar nicht narrow, eher narrisch.


;-)

Was passiert mit dem *202F* von InDesign CS3 beim Import in QXP?
Wirkt es so, wie wenn es als *202F* in QPX eingegeben worden wäre?

Antwort auf: Bugreport: Ich bin definitiv nicht »Albert« ;-)

Hattest Du nicht 'phantasievoll' so unterschrieben? ;-)


als Antwort auf: [#335623]

Private Use Area

xpressio
Beiträge gesamt: 1584

7. Feb 2008, 18:45
Beitrag # 9 von 11
Beitrag ID: #335653
Bewertung:
(5559 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Antwort auf: Was passiert mit dem *202F* von InDesign CS3 beim Import in QXP?
Wirkt es so, wie wenn es als *202F* in QPX eingegeben worden wäre?

Eben nicht. Es wird so wie wenn die Datei aus Word importiert worden wäre – es würde sich also in jedem Fall ein Neuumbruch ergeben.

Wandelt man die Datei in ein PDF, bleibt der ZWR erhalten. Bei einer Umwandlung in eine HTML-Datei fliegt er ersatzlos raus.

Im Anhang habe ich das verdeutlicht:

Der erste Block zeigt die Darstellung in QXP in einem Print-Dokument bei angezeigten Sonderzeichen aller ZWR – 1. Reihe ungeschützt, 2. Reihe geschützt.

Der zweite Block zeigt die Darstellung in einem Web-Dokument. Hier werden nur mehr die ZWR *Geviert*, *Halbgeviert*, *Achtelgeviert* (Thin space) sowie *Abstand mit Nullbreite* (Word Joiner) übernommen. Alle anderen ZWR werden als Standard-ZWR angezeigt.

Der dritte Block zeigt die Darstellung nach Umwandlung in eine HTML-Datei im Browser. Hier lässt sich erkennen, dass sich die Breite der Zwischenräume nicht immer nach der Anzeige in QXP richtet.

Der vierte Block zeigt die HTML-Codierung, die erkennen lässt, dass nur *Geviert*, *Halbgeviert* und *Achtelgeviert* definiert sind. Die restlichen ZWR sind als Standard-ZWR ausgewiesen, in der Darstellung jedoch teilweise unterschiedlich breit, d.h. die tatsächliche Codierung ist unsichtbar.

Für die Entwickler gibt’s also hier noch einiges zu tun, bis das übereinstimmt.


als Antwort auf: [#335631]
Anhang:
wzrs.jpg (67.5 KB)

Private Use Area

typografie.info
Beiträge gesamt: 403

7. Feb 2008, 22:44
Beitrag # 10 von 11
Beitrag ID: #335695
Bewertung:
(5537 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Zum Windings-Problem:
Wie sich herausgestellt hat, ist es in Wahrheit ein Problem in MacOS X. InDesign CS2 bezieht von MacOS X das Unicode-Mapping, dass bei Symbol Fonts wie Windings leider versagt.
In CS3 wird das Unicode-Mapping direkt aus dem Font benutzt. Daher die Inkompatibilität.

In CS2 gibt es erfreulicherweise auch einen Work-around: Die Symbol Fonts müssen im InDesign-Font-Ordner installiert werden, dann wird das fehlerhafte Mapping des OS übergangen.

Ralf


als Antwort auf: [#335653]

Private Use Area

Martin Fischer
Beiträge gesamt: 12783

8. Feb 2008, 10:11
Beitrag # 11 von 11
Beitrag ID: #335743
Bewertung:
(5504 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Ralf,

das macht die Sache klarer, verständlicher und nachvollziehbar.
Ich danke für Deine Mühe.


als Antwort auf: [#335695]
X

Aktuell

Veranstaltungskalender

Hier können Sie Ihre Anlässe eintragen, welche einen Zusammenhang mit den Angeboten von HilfDirSelbst.ch wie z.B. Adobe InDesign, Photoshop, Illustrator, PDF, Pitstop, Affinity, Marketing, SEO, Büro- und Rechtsthemen etc. haben. Die Einträge werden moderiert freigeschaltet. Dies wird werktags üblicherweise innert 24 Stunden erfolgen.

pdf-icon Hier eine kleine Anleitung hinsichtlich Bedeutung der auszufüllenden Formularfelder.

Veranstaltungen
14.05.2024

Online
Dienstag, 14. Mai 2024, 10.00 - 10.30 Uhr

Webinar

Prozessoptimierung ist ein Teamsport! Keine Software und keine Maschine allein kann Ihnen helfen, die Effizienzpotenziale Ihres Betriebes maximal auszuschöpfen. Von der Auftragsannahme über die Vorstufe und den Druck bis hin zur Weiterverarbeitung – alles muss optimal ineinandergreifen. Apropos Weiterverarbeitung – in vielen Druckbetrieben fristet sie in Sachen Prozessoptimierung immer noch ein Schattendasein. Dabei liegen hier mittlerweile die größten Einsparpotenziale! In einem Webinar von Horizon und Impressed erfahren Sie, wie Sie diese Einsparungen realisieren können. Horizon, bekannt für innovative Lösungen in der Druckweiterverarbeitung, bietet mit iCE LiNK eine Workflowlösung für die Weiterverarbeitung. iCE LiNK überwacht, visualisiert und analysiert Produktionsabläufe und unterstützt bei der Wartung – damit immer alles reibungslos läuft. Den gleichen Anspruch hat der von Impressed entwickelte Impressed Workflow Server – er ist die smarte PDF-Workflow-Lösung für Druckereien, die Datenmanagement, Preflight und Produktionssteuerung übernimmt. Im Webinar zeigen Ihnen die Experten von Horizon und Impressed, wie beide Lösungen im Team die Effizienz und Produktivität Ihres Betriebes steigern können. Melden Sie sich am besten gleich an, wir freuen uns auf Sie! PS: Melden Sie sich in jedem Fall an – sollten Sie zum Termin verhindert sein, erhalten Sie die Aufzeichnung.

kostenlos

Ja

Organisator: Impressed / Horizon

https://www.impressed.de/schulung.php?c=sDetail&sid=327

Einsparpotenziale in der Weiterverarbeitung
Veranstaltungen
16.05.2024

Online
Donnerstag, 16. Mai 2024, 10.00 - 10.30 Uhr

Webinar

Komplizierte, kleinteilige Aufträge; alles sehr speziell; seit Jahren bewährte Prozesse – da können wir nichts standardisieren und automatisieren! Das sagen viele Großformatdrucker – aber stimmt das wirklich, ist dem tatsächlich so? Günther Business Solutions und Impressed treten in einem Webinar den Gegenbeweis an. Experten beider Unternehmen zeigen, wie Großformatdrucker vom Einsatz zweier bewährter Lösungen profitieren können: • von advanter print+sign von Günther Business Solutions, dem ERP-System für den Großformatdruck, dass alle Phasen der Wertschöpfung im Large Format Printing abdeckt • von Impressed Workflow Server, der smarten PDF-Workflow-Lösung für Druckereien, die Datenmanagement, Preflight und Produktionssteuerung übernimmt Über die Kombination beider Lösungen können Großformatdrucker ihre Prozesse mit modernen Workflows Schritt für Schritt automatisieren – und so zügig deutliche Zeit- und Kosteneinsparungen realisieren. Das Webinar sollten Sie sich nicht entgehen lassen – damit Sie keine Effizienzpotenziale mehr liegen lassen. Melden Sie sich am besten gleich an, wir freuen uns auf Sie! PS: Melden Sie sich in jedem Fall an – sollten Sie zum Termin verhindert sein, erhalten Sie die Aufzeichnung.

kostenlos

Nein

Organisator: Impressed / Günther Business Solutions

https://www.impressed.de/schulung.php?c=sDetail&sid=326

Und es geht doch: Automatisierung im Großformatdruck!