E-mail List Archives
Re: Do fonts have to be embedded in a WCAG 2.0conformingPDFdocument?
From: Andrew Kirkpatrick
Date: Apr 15, 2015 2:48PM
- Next message: Jesse Hausler: "Re: menuitemradio and menuitemcheckbox with iOS VoiceOver"
- Previous message: Karen Sorensen: "Thanks Jennison!"
- Next message in Thread: Olaf Drümmer: "Re: Do fonts have to be embedded in a WCAG 2.0conformingPDFdocument?"
- Previous message in Thread: Olaf Drümmer: "Re: Do fonts have to be embedded in a WCAG 2.0 conformingPDFdocument?"
- View all messages in this Thread
Olaf,
Would you say that a PDF that is all in French, uses adobe's internal font (which is not available externally - adobe clean), and does all of the things that are needed to expose accessible information except doesn't embed the font is going to cause issues for any users? If so, what?
Andrew Kirkpatrick
> On Apr 15, 2015, at 3:46 PM, Olaf Drümmer < <EMAIL REMOVED> > wrote:
>
> Not embedding a font could lead to a situation where visually presenting a PDF depends on certain resources to be available (and visual presentation would fail to be useful if such resource is missing). Due to the way PDF works, the situation is not the same as in HTML-land, where a user agent for visual presentation is prepared to at least support all the scripts that the user of the user agent will understand (and lots of HTML pages do not reference a specific font file or specific font resource anyway, though this is currently changing, albeit typically with reasonable fallbacks in place).
>
> We Westerners do not necessarily run into issues with non-embedded fonts in PDF because tools do an excellent job in providing a fallback - though limited to what Andrew introduced as "Latin-1" (a set of characters used in 'Western' regions, i.e. most of Western Europe and the Americas). Take Cyrillic or Greek scripts, and you are looking at a completely different story, not to mention scripts in Thailand, India, China, Japan, Korea, or Arabic and Hebrew scripts…
>
> Along the same lines a PDF file claiming to be accessible must also always ensure that each and every piece of text can be interpreted on the background of Unicode.
>
>
> Both - embedded fonts and complete mapping to Unicode - are two absolute requirements to enable accessibility. That's why they are required in the PDF/UA standard. Based on its tendency to be technology agnostic, WCAG2 seems to miss the boat in this regard when it comes to PDF.
>
>
> Olaf
>
>
>
>> On 15 Apr 2015, at 21:06, Andrew Kirkpatrick < <EMAIL REMOVED> > wrote:
>>
>> Catching up on this thread...
>>
>> Can you have a WCAG 2.0-conforming PDF document without embedded fonts? Yes.
>>
>> Will all users be able to read the text in that document? No, not always.
>>
>> When you don't embed a font in a PDF document the textual information still exists within the document and is used to populate the accessibility structure for the document. If you don't embed the font then Adobe Acrobat Reader (and earlier versions of Reader) will map the text information to a Latin-1 font. If you are starting with a font that uses the same characters as a Latin-1 font then Reader will do its best to match the font by name or by appearance with a font that the user has available on their system.
>>
>> The situation is very much like in HTML when an author references a font that they have on their system but that other end-users may not. Browsers can make their best guess, and that may work out in many cases but not all.
>>
>> Is having a font that is different from the author's original intent an accessibility issue? I don't think so.
>>
>>> - Some users may depend on characteristics such as word-spacing, line-spacing, text alignment, etc to understand the document. As one example, imagine a screen magnifier user dealing with text in which the breaks between words aren't clear, or where characters overlap. A conventional user might have the problem to a limited extent, but the user running the magnifier is much more likely to be very seriously affected.
>>
>> But this is no different an issue than if an author chose one of the fonts that the PDF reader used as the replacement when creating the document to begin with, so I disagree that this is an accessibility issue.
>>
>>> - AT software that replaces or manipulates fonts (for example to accommodate those with dyslexia) will not be able to function predictably (if at all).
>>
>> I don't understand why this would be a problem. If the AT discards the font that is referenced and replaces it with a different font that is available, how does a negative result present?
>>
>>>> It seems that this is an overall usability issue for all people
>>
>>> It is certainly that, but it also disproportionally affects users with disabilities.
>>
>> I'm not sure how that is an accurate statement yet. As far as I can tell it isn't having a disproportionate effect.
>>
>>> …but which SC?
>>
>> Barring additional new information I'd say "none".
>>
>> AWK
>> >> >> >> >
> > > >
- Next message: Jesse Hausler: "Re: menuitemradio and menuitemcheckbox with iOS VoiceOver"
- Previous message: Karen Sorensen: "Thanks Jennison!"
- Next message in Thread: Olaf Drümmer: "Re: Do fonts have to be embedded in a WCAG 2.0conformingPDFdocument?"
- Previous message in Thread: Olaf Drümmer: "Re: Do fonts have to be embedded in a WCAG 2.0 conformingPDFdocument?"
- View all messages in this Thread