Barrierefreies PDF: Acrobat stolpert über Umlaute

[[Mitglied Micr…]]

Wir kämpfen hier gerade mit einem barrierefreien PDF welches erstellt werden soll. Leider liesst Acrobat die Umlaute nicht vor - egal ob der Text in Arial oder einer anderen Schrift gesetzt ist. 

 

Hat jemand eine Lösung parat?

[[Mitglied Micr…]]

Huhu!

[[Mitglied Norb…]]

Ich erinnere mich nur dunkel, aber erwartet Acrobat nicht irgendwo, dass man schon im Quelltext irgendwie die Ausgabesprache festgelegt hat?

[[Mitglied 746e…]]

Was ich dazu auf hds gelesen hab, ist nichts Gutes … meist scheitert es an der Codierung, manchmal werden Alternativtexteingaben unterschiedlich behandelt, abhängig davon ob sie per Hand in Acrobat eingegeben wurden oder aus einer Layoutsoftware kommen. Ein Lösung habe ich leider nicht.

[[Mitglied Þors…]]

Ich kenne mich mit text-to-speech jetzt nicht so aus, aber es würde mich schon sehr wundern, wenn der gewählte Font in einem PDF darauf Einfluss hätte. Was veranlasst dich zu dieser Annahme? Ich würde mal vermute, dass die Screenreader-Software einfach die im Dokument kodierten Zeichen nimmt. So ist es jedenfalls bei allen Optionen, die ich hier in Linux habe. OCR anhand der Buchstabenbilder – und nur dort käme m.E. der Font ins Spiel – macht da keine. (Das heißt dann auch, dass PDFs, in denen die Texte nur als Kurven vorliegen, prinzipiell nicht vorlesbar sind. Ich vermute jetzt mal einfach, dass das mit den gängigen Lösungen auf in Mac OS und Windows auch so ist.)

 

Und wenn Umlaute also nicht vorgelesen werden, liegt es, wie bertel schon angedeutet hat, wahrscheinlich entweder an einem falschen  character encoding oder an einer falsch eingestellten Sprache. Was ich an deiner Stelle testen würde:

• Wie werden die Texte denn von den Umlauten abgesehen vorgelesen? Klingt es nach (synthetischem) Deutsch?
• Wie wird denn ß behandelt?

 

[[Mitglied catf…]]

und an ſ und ẞ dürfte das dann vollends Kapitulieren?

[[Mitglied Þors…]]

Zumindest können Texte mit ſ prinzipiell nicht barrierefrei sein.

[[Mitglied catf…]]

wäre aber wohl nicht so schwer umzusetzen.

[[Mitglied Micr…]]

In InDesign ist als Ausgabesprache deutsch eingestellt und so klingt es auch. Acrobat meldet bei seinem Check auch keinen Fehler. Das die Zeichen falsch kodiert sind würde ich ausschliessen - dann wären sowohl Arial als auch Flama falsch kodiert.

[[Mitglied Þors…]]

Die Annahme wäre ja nicht, dass der Font falsch kodiert ist, sondern dass die irgendwo zwischen PDF und Vorlesesoftware eine falsche Kodierung angenommen wird. In welcher Kodierung ist das Dokument denn, UTF-8? Hast du mal PDFs versucht, die nicht mit (eurem)  ID erstellt wurden? Und ich wiederhole noch mal meine Frage: wird ß richtig vorgelesen?

[[Mitglied Muec…]]

Problem inzwischen gelöst?

Erinnert mich bissele an PDFs aus LaTeX. Die sehen auf Papier und PDF gut aus, aber zumindest ältere sind intern gebastelt ...

Habe mal eben ein PDF aus 2007 durch pdftotext gescheucht, Ausgabe:

 

ein a ¨ ußerst ung¨ unstigs Timing.

 

Und nur das fehlende e ist ein Tippfehler, nach 9 Jahren nun endlich entdeckt ...

Der Rest kommt von LaTeX, das die Umlaute (damals jedenfalls mit \documentstyle[german,12pt,a4,umlaut,times]{article}) aus Buchstabe und Diaeresis gebastelt hat ...

 

[[Mitglied natr…]]

Hallo zusammen, ich habe Microboys Beitrag erst jetzt gelesen. Hatte ein ähnliches Problem, allerdings nicht beim Vorlesen, sondern der Darstellung. War zu lösen in dem man den/die betreffenden Font(s) z.B. in FontForge öffnet und in ein .otf umwandelt (sofern .ttf vorliegt), das muss man allerdings mit jedem einzelnen Schnitt machen. Danach wird alles fehlerfrei dargestellt. Es wäre vielleicht einen Versuch wert. Betrifft das mehr als zwei oder drei Fonts ist der Aufwand natürlich zu groß. Und irgendwann sollte das Problem seitens Adobe gelöst sein. 

[[Mitglied Þors…]]

Was waren das denn für Fonts? Sehr alte, noch nicht Unicode-kodierte? Meine erste Vermutung wäre, dass Fontforge die dann einfach korrekt in Unicode kodiert geschrieben und das Problem so behoben hat. Mit dem Fontformat, TTF oder OTF, hätte das also nichts zu tun. Du hättest den Font auch wieder als TTF schreiben können. Denn natürlich können Adobe-Programme (zumindest was die Darstellung angeht) problemlos Umlaute mit korrekt kodierten TTF-Fonts verarbeiten. Oder wie jetzt?

[[Mitglied natr…]]

Hi, das war ein relativ neuer Font und zwar die DejaVu Sans/Book/Cond... Irgendwo im Netz stand dass Adobe in der neuesten Acrobat-Version teilweise Darstellungsfehler produziert, der Bug sei bekannt, aber eben noch nicht behoben. Zur schnellen Lösung wurde das so vorgeschlagen. Aber stimmt, zum Testen hätte ich auch .ttf probieren können, die Zeit iwar halt wie immer knapp und ich war einfach froh, dass es geklappt hatte.

[[Mitglied Þors…]]

Danke für die Info. Ist ja extrem merkwürdig. Ich bin mir ziemlich sicher, dass täglich tausende Texte mit Adobe-Produkten und TTF-Fonts gesetzt werden, in denen Umlaute korrekt dargestellt werden. Alles andere wäre ja ein Adobe-Killer für deutschsprachige Anwendungen.

 

Hat jemand von den Adobe benutzenden Kollegen das schon mal erlebt?

 

[[Mitglied natr…]]

das ist natürlich nicht bei allen .ttf Fonts passiert. 

[[Mitglied Þors…]]

Die hier?

Ich habe sie mir gerade mal angesehen. Da sieht auch intern alles prima aus. Alle Umlaute liegen, wie man das erwartet, auch pre-composed  auf den richtigen Unicode-Positionen vor. Keine Ahnung, was da schief gehen könnte.

[[Mitglied natr…]]

moah, halt eben alle Schnitte der DejaVu Sans, meine Formulierung war dir zu schludrig, stimmt's? Also bei mir sah die alles andere als gut aus. Aber womöglich hat sich das Problem inzwischen gelöst, ich dachte halt ich sag mal Bescheid. Und sobald mein Kürbis fertig ist, gehe ich nochmal auf die Suche nach dem Beitrag im Netz...

[[Mitglied Þors…]]

Ne, ich hatte nur nachgefragt, weil die hier auf meinem System nur als Sans Condensed (Regular) auftrifft. Aber es stimmt, DejaVu selbst nennt diesen Schnitt anscheinend  Book.

[[Mitglied catf…]]

Nun ja, wie seltsam sich manches verhält, und an welchen Stellen Fallstricke lauern, hatte ich ja im Mai 15 mit dieser Nord-Problematik, mit der ich auch noch nicht wirklich weiter bin, außer dass ich halt Nord vermeide.

 

Mittlerweile bin ich dann auch ver-Apple-t und kann so was besser kontrollieren. aber ich hab noch nicht getestet, wie es jetzt in Sierra läuft - da hab ich derzeit noch andere Problermchen.

 

Hier der Strang von damals:

 

E+F haben sich übrigens nicht mehr gemeldet, aber egal...

 

[[Mitglied natr…]]

ja, ist auf meinen System ebenso – aber die Bezeichnung Book für den Schnitt regular ist doch normal? Was für ein Satz… 

[[Mitglied natr…]]

Die Quelle im Netz habe ich gefunden:

 Link zum Beitrag

Mittlerweile ist er angeblich per Update behoben worden, das wusste ich gestern allerdings noch nicht.

Ob das in irgend einer Weise bei der Lösung des oben genannten Problems helfen könnte – womöglich nein, aber vielleicht ein bisschen :/