E-mail List Archives
Re: A case for artifacting bullets in unordered lists in PDFs
From: Olaf Drümmer
Date: Jul 23, 2013 9:20AM
- Next message: Sailesh Panchang: "Re: A case for artifacting bullets in unordered lists in PDFs"
- Previous message: Jonathan Metz: "Re: A case for artifacting bullets in unordered lists in PDFs"
- Next message in Thread: Sailesh Panchang: "Re: A case for artifacting bullets in unordered lists in PDFs"
- Previous message in Thread: Jonathan Metz: "Re: A case for artifacting bullets in unordered lists in PDFs"
- View all messages in this Thread
Hi Jonathan,
Am 23 Jul 2013 um 16:21 schrieb Jonathan Metz < <EMAIL REMOVED> >:
> Currently I¹m working with someone who insists that unordered lists should
> have a <Lbl> in the tag tree if there is a graphic or glyph representing
> the 'bullet' character. My approach to unordered lists in PDFs is to
> artifact the bullet character.
my take:
- characters used for bullets in bulleted lists (from my point of view) are not an accidental by-product of doing page layout / pagination (they exist also on web pages, where no such layout / pagination happens)
- by definition this implies that they cannot be artifacted just because they happen to be in front of list items
- so if they are present, and as they might convey information, they have to be made accessible
- PDF and PDF/UA require that such bullet character is put inside a <Lbl> tag
- in most documents the bullet character is a well defined character (the usual bullet character comes with a Unicode code point, U+2022, and that code point is not in the private use area); thus nothing extra (like applying an ActualText attribute) has to be done in such cases as the character can be pronounced as "bullet" by a screen reader (or the respective word in other languages)
- there might be cases where the bullet point is something other than the usual bullet character; as long as that other character has a well defined Unicode code point outside the private use area, all is fine, no extra work necessary (you can actually check this if you use callas pdfGoHTML: if the bullet character looks the same as in PDF, the Unicode code point seems to work OK, if you see replacement characters, usually empty square characters, it is probably using a private use area code point (private use area - PUA - means that no predefined meaning is associated with code points in this PUA area), and in this case some extra work is necessary (see next list item [pun intended ;-) ]).
- in some cases pictorials are used (or characters without well defined Unicode code point, or a Unicode code point from the private use area) - either a piece of vector graphic, an image, a non-Unicode character, or whatever: in such cases, one may have to use the ActualText (if the content of these pictorials is more like text, or maybe a bullet point drawn in a fancy or multi-colored way, but still looking like a bullet point) or Alt attribute (if the pictorials are more like images) on the content inside the Lbl (not on the Lbl, please).
It will be up to assistive technology (AT) how to present the contents of the Lbl tag. I can understand why some users would want to turn off (at least some of the time) reading out / displaying the Lbl - but it must be possible, if configured accordingly, that access to Lbl is provided.
HTH.
Olaf
- Next message: Sailesh Panchang: "Re: A case for artifacting bullets in unordered lists in PDFs"
- Previous message: Jonathan Metz: "Re: A case for artifacting bullets in unordered lists in PDFs"
- Next message in Thread: Sailesh Panchang: "Re: A case for artifacting bullets in unordered lists in PDFs"
- Previous message in Thread: Jonathan Metz: "Re: A case for artifacting bullets in unordered lists in PDFs"
- View all messages in this Thread