Re: Org source in PDF (Re: Org mode export accessibility)

[Timothy]

Hi Max,

Just for reference, I (automatically) embed the `.tex' and `.org' source files 
in PDFs I
produce.

Max Nikulin  writes:

> It is unrelated to accessibility, but I have heard that OpenOffice may embed
> original document into generated PDF to allow “edit PDF” feature. Instead of
> attempting to map PDF content onto ODT structures it just extracts and opens 
> for
> edit document source. My curiosity has been never strong enough to find 
> details
> related to the implementation.

All the best,
Timothy

Org source in PDF (Re: Org mode export accessibility)

[Max Nikulin]

On 01/10/2022 11:36, Ihor Radchenko wrote:


Also, would it help to embed an Org source into the generated PDF?


It is unrelated to accessibility, but I have heard that OpenOffice may 
embed original document into generated PDF to allow "edit PDF" feature. 
Instead of attempting to map PDF content onto ODT structures it just 
extracts and opens for edit document source. My curiosity has been never 
strong enough to find details related to the implementation.

Re: Org mode export accessibility

[T.V Raman]

Ihor Radchenko  writes:


No on both counts.
> "T.V Raman"  writes:
>
>> 8. Now, connect the dots, newer LaTeX packages like the one mentioned
>>(there may well be others now or in the future) can inprinciple
>>ensure that the required "back pointers to regenerate the original
>>markup" can make it all the way through  to the generated PDF.
>
> Are you aware of such other available LaTeX packages?
>
> Also, would it help to embed an Org source into the generated PDF? If it
> is, is there a preferred way to indicate that the generated PDF contains
> Org source?

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
?7?4 Id: kg:/m/0285kf1  ?0?8

Re: Org mode export accessibility

[Ihor Radchenko]

"T.V Raman"  writes:

> 8. Now, connect the dots, newer LaTeX packages like the one mentioned
>(there may well be others now or in the future) can inprinciple
>ensure that the required "back pointers to regenerate the original
>markup" can make it all the way through  to the generated PDF.

Are you aware of such other available LaTeX packages?

Also, would it help to embed an Org source into the generated PDF? If it
is, is there a preferred way to indicate that the generated PDF contains
Org source?

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

Re: Org mode export accessibility

[T.V Raman]

correct; user-facing tools are still lacking but that shouldn't cause
us to wait since that creates a chicken-and-egg problem.

Max Nikulin writes:
 > On 30/09/2022 20:29, T.V Raman wrote:
 > > 
 > > 9. Note that this is not the end of the trail; for such exports to
 > > make a difference to the end-user, user-facing tools still need to
 > > know "how" to leverage these facilities.
 > 
 > Do you mean that there are no tools yet that may take advantage of math 
 > expressions embedded into PDF as LaTeX source markup? I am just trying 
 > to figure out current state of affairs. I suppose, it is unlikely that 
 > someone from Org mailing list subscribers is ready to invest significant 
 > amount of time into development of LaTeX packages. However if there were 
 > ready to use and safe packages improving accessibility then changing 
 > export templates would be more real goal.
 > 
 > In the meanwhile I have realized that \usepackage{mmap} has a little use 
 > in isolation. Fractions, indices, etc. are lost. Maybe some other 
 > packages should be loaded to provide more informative text equivalent 
 > for math.
 > 
 > Some details concerning what I have tried is below.
 > 
 > Original LaTeX expression:
 > 
 > Text \[ \int_{\alpha}^{\beta} \frac{dx}{x^2 + \varepsilon} \]
 > 
 > pdftotext -layout output for \usepackage{mmap}:
 > Text   \int \beta
 > dx
 > \alphax2 + \varepsilon
 > 
 > end of output
 > 
 > pdftotext output for \usepackage{cmap} and \usepackage[noTeX]{mmap}:
 > Text   ∫︁   𝛽
 >𝑑𝑥
 >  𝛼   𝑥2 + 𝜀
 > 
 > end of output
 > 
 > pdftotext output when neither cmap nor mmap is loaded:
 > Text   Z   β
 >   dx
 > α   x2 + ε
 > 
 > end of output
 > 
 > For this dumb example effect of mmap is hardly noticeable. Integral 
 > symbol is not replaced by "Z", but it is hard to guess sub- and 
 > superscripts and presence of the \frac command. Without "-layout" order 
 > of symbols is mostly preserved, but structure is lost
 > 
 > Text
 > ∫︁
 > 
 > 𝛽
 > 
 > 𝛼
 > 
 > 𝑑𝑥
 > 𝑥2 + 𝜀

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

Re: Org mode export accessibility

[Max Nikulin]

On 30/09/2022 20:29, T.V Raman wrote:


9. Note that this is not the end of the trail; for such exports to
make a difference to the end-user, user-facing tools still need to
know "how" to leverage these facilities.


Do you mean that there are no tools yet that may take advantage of math 
expressions embedded into PDF as LaTeX source markup? I am just trying 
to figure out current state of affairs. I suppose, it is unlikely that 
someone from Org mailing list subscribers is ready to invest significant 
amount of time into development of LaTeX packages. However if there were 
ready to use and safe packages improving accessibility then changing 
export templates would be more real goal.


In the meanwhile I have realized that \usepackage{mmap} has a little use 
in isolation. Fractions, indices, etc. are lost. Maybe some other 
packages should be loaded to provide more informative text equivalent 
for math.


Some details concerning what I have tried is below.

Original LaTeX expression:

Text \[ \int_{\alpha}^{\beta} \frac{dx}{x^2 + \varepsilon} \]

pdftotext -layout output for \usepackage{mmap}:
Text   \int \beta
   dx
   \alphax2 + \varepsilon

end of output

pdftotext output for \usepackage{cmap} and \usepackage[noTeX]{mmap}:
Text   ∫︁   𝛽
  𝑑𝑥
𝛼   𝑥2 + 𝜀

end of output

pdftotext output when neither cmap nor mmap is loaded:
Text   Z   β
 dx
   α   x2 + ε

end of output

For this dumb example effect of mmap is hardly noticeable. Integral 
symbol is not replaced by "Z", but it is hard to guess sub- and 
superscripts and presence of the \frac command. Without "-layout" order 
of symbols is mostly preserved, but structure is lost


Text
∫︁

𝛽

𝛼

𝑑𝑥
𝑥2 + 𝜀

Re: Org mode export accessibility

[T.V Raman]

As one example, yes.

Here is hopefully a more detailed explanation:

1. First off, here Accessibility == Specifically, Accessibility to the
   blind.
2. For blind and low vision users, you may need to "re-render" the
   math, either via magnification, speech or Braille.
3. For doing this, you need the original "generating markup" MathML,
   or better yet LaTeX (those distinctions  require more  explanation,
   but this should suffice for this thread)
4. When things are rendered to PDF, a derivative format that traces
   back to the print world and traditionally didn't feel the need to
   recreate the original, all that info from (3) is lost.
5. For regular document structure, e.g. headings etc, PDF now supports
   this "natively" via something called "marked content" introduced in
   the late 90's; to leverage this, publishing tools exporting to PDF
   can leverage that facility to enable downstream tools re-create or
   extract an approximation of the original structure. 
6. The above left out Math --- mostly because authoring tools did not
   go as far as doing that for Math.
7. Then you got  pdftex that replaced DVI (which was essentially pure
   visual layout) with PDF -- also pure visual layout -- but a format
   that has continued to evolve.
8. Now, connect the dots, newer LaTeX packages like the one mentioned
   (there may well be others now or in the future) can inprinciple
   ensure that the required "back pointers to regenerate the original
   markup" can make it all the way through  to the generated PDF.
9. Note that this is not the end of the trail; for such exports to
   make a difference to the end-user, user-facing tools still need to
   know "how" to leverage these facilities.


Max Nikulin writes:
 > Accessibility issues of exported files have been raised on the Org mode 
 > mail list again. I decided to revive this thread because I noticed a 
 > LaTeX package that may be related to the following suggestion (I am not 
 > sure that I got it right though).
 > 
 > On 07/07/2022 21:42, T.V Raman wrote:
 > > 
 > > 3. For math especially, make sure the TeX/LaTeX is preserved one
 > >way  or the other in the export
 > 
 > Math can be extracted from PDF files as TeX commands using e.g. 
 > pdftotext if LaTeX source file contains \usepackage{mmap}. Is it what 
 > you were writing about?
 > 
 > https://ctan.org/pkg/mmap
 > https://mirrors.ctan.org/macros/latex/contrib/mmap/README
 > 
 > The latest thread with discussion of accessibility:
 > 
 > https://list.orgmode.org/th4dth$5df$1...@ciao.gmane.io
 > Max Nikulin Re: Add \usepackage{cmap} as default LaTeX class in ox-latex 
 > (was: org exported pdf files) Thu, 29 Sep 2022 22:34:07 +0700.

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

Re: Org mode export accessibility

[Max Nikulin]

Accessibility issues of exported files have been raised on the Org mode 
mail list again. I decided to revive this thread because I noticed a 
LaTeX package that may be related to the following suggestion (I am not 
sure that I got it right though).


On 07/07/2022 21:42, T.V Raman wrote:


3. For math especially, make sure the TeX/LaTeX is preserved one
   way  or the other in the export


Math can be extracted from PDF files as TeX commands using e.g. 
pdftotext if LaTeX source file contains \usepackage{mmap}. Is it what 
you were writing about?


https://ctan.org/pkg/mmap
https://mirrors.ctan.org/macros/latex/contrib/mmap/README

The latest thread with discussion of accessibility:

https://list.orgmode.org/th4dth$5df$1...@ciao.gmane.io
Max Nikulin Re: Add \usepackage{cmap} as default LaTeX class in ox-latex 
(was: org exported pdf files) Thu, 29 Sep 2022 22:34:07 +0700.

Re: Org mode export accessibility

[T.V Raman]

Ihor Radchenko  writes:

What can or cannot be preserved is a function of the export format.

MathJax is a wonderful thing and the LaTeX expression embedded in the
HTML is the best one can do -- MathML loses semantics -- which is why I
always recommend preserving the LaTeX when going to HTML.

PDF as a format doesn't have the affordance to preserve the LaTeX and
even if you kluged up something --- the tools to extract that out of the
PDF would need to be invented.

> "T.V Raman"  writes:
>
>>  > >   3. For math especially, make sure the TeX/LaTeX is preserved one
>>  > >  way  or the other in the export
>>  > 
>>  > Do you refer to the TeX source? To any specific export format?
>> 2. Math: Yes -- I meant the TeX/LaTeX representation of a math
>>expression.
>>Ihor Radchenko writes:
>
> For html export we do preserve TeX/LaTeX representation because we use
> Mathjax that directly supports such representation.
>
> However, I am not sure how to preserve the original representation, say,
> in LaTeX pdf export.
>
> Best,
> Ihor

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
?7?4 Id: kg:/m/0285kf1  ?0?8

Re: Org mode export accessibility

[Ihor Radchenko]

"T.V Raman"  writes:

>  > >   3. For math especially, make sure the TeX/LaTeX is preserved one
>  > >  way  or the other in the export
>  > 
>  > Do you refer to the TeX source? To any specific export format?
> 2. Math: Yes -- I meant the TeX/LaTeX representation of a math
>expression.
>Ihor Radchenko writes:

For html export we do preserve TeX/LaTeX representation because we use
Mathjax that directly supports such representation.

However, I am not sure how to preserve the original representation, say,
in LaTeX pdf export.

Best,
Ihor

Re: Org mode export accessibility

[T.V Raman]

1. Labels: yes -- figure captions etc. are examples of "labels" in
   general.

2. Math: Yes -- I meant the TeX/LaTeX representation of a math
   expression.
   Ihor Radchenko writes:
 > "T.V Raman"  writes:
 > 
 > > On org side:
 > 
 > Thanks for the feedback!
 > 
 > > 1. During authoring, ensure that authors have the ability to label
 > >images, drawings and math content.
 > >2. When exporting, make sure that that information gets through to
 > >   the exported format.
 > 
 > Could you please elaborate what you mean by "label"?
 > 
 > Org generally supports figures and equations in export, including adding
 > captions - all specific to the corresponding export backends (when the
 > backends support figures/equations).
 > 
 > >   3. For math especially, make sure the TeX/LaTeX is preserved one
 > >  way  or the other in the export
 > 
 > Do you refer to the TeX source? To any specific export format?
 > 
 > Best,
 > Ihor

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

Re: Org mode export accessibility

[T.V Raman]

Correct.
1. Org should be the truth, not some export format that is picked
   based on political opinion.

2. Lowest Common denominator in my vocabulary is a "bad word" that LCD
   is something that makes everyone equally unhappy.

   So Take-Away:

   1. Make org the best format for holding the authored content.
  2. Consider all exports to be either modality or use-case
 specific and produce the  best version that that export
 format can support.

 3. But then dont fall into the delusion that the export
format is the truth --

   

Ihor Radchenko writes:
 > briangpowell  writes:
 > 
 > > Suggest OrgMode outputs focus on creating "Lowest Common Denominator"
 > > documents as output:
 > > TeXinfo docs should be used as the LCD doctype--suggest you focus on
 > > creating 1 document in Texinfo that you use to create all other sorts of
 > > documents, when possible:
 > >
 > > Pipeline should be more like
 > > OrgMode->Texinfo->TROFF||DTD/XML/HTML/XHTML->LaTeX/TeX->DVI||SVG->PS->PDF
 > >
 > > * TeXinfo: https://savannah.gnu.org/projects/texinfo
 > > https://www.gnu.org/software/texinfo
 > 
 > I do not think that using Texinfo as intermediate format is useful.
 > Texinfo does not support many of the available Org syntax structures
 > like, for example, backend-specific export blocks. We will inevitably
 > lose some document structure information when exporting to Texinfo.
 > Please remember that Texinfo is by no means a generic export engine - it
 > is tailored to produce software documentation specifically and may not
 > be suitable for more generic authored documents.
 > 
 > Note that we already have a much more feature-full export functionality.
 > RMS even suggested that Org might be used as a replacement for Texinfo:
 > https://yhetil.org/emacs-devel/e1nzqh5-0001ob...@fencepost.gnu.org
 > 
 > Best,
 > Ihor

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

Re: Org mode export accessibility

[Ihor Radchenko]

"T.V Raman"  writes:

> On org side:

Thanks for the feedback!

> 1. During authoring, ensure that authors have the ability to label
>images, drawings and math content.
>2. When exporting, make sure that that information gets through to
>   the exported format.

Could you please elaborate what you mean by "label"?

Org generally supports figures and equations in export, including adding
captions - all specific to the corresponding export backends (when the
backends support figures/equations).

>   3. For math especially, make sure the TeX/LaTeX is preserved one
>  way  or the other in the export

Do you refer to the TeX source? To any specific export format?

Best,
Ihor

Re: Org mode export accessibility

[Ihor Radchenko]

briangpowell  writes:

> Suggest OrgMode outputs focus on creating "Lowest Common Denominator"
> documents as output:
> TeXinfo docs should be used as the LCD doctype--suggest you focus on
> creating 1 document in Texinfo that you use to create all other sorts of
> documents, when possible:
>
> Pipeline should be more like
> OrgMode->Texinfo->TROFF||DTD/XML/HTML/XHTML->LaTeX/TeX->DVI||SVG->PS->PDF
>
> * TeXinfo: https://savannah.gnu.org/projects/texinfo
> https://www.gnu.org/software/texinfo

I do not think that using Texinfo as intermediate format is useful.
Texinfo does not support many of the available Org syntax structures
like, for example, backend-specific export blocks. We will inevitably
lose some document structure information when exporting to Texinfo.
Please remember that Texinfo is by no means a generic export engine - it
is tailored to produce software documentation specifically and may not
be suitable for more generic authored documents.

Note that we already have a much more feature-full export functionality.
RMS even suggested that Org might be used as a replacement for Texinfo:
https://yhetil.org/emacs-devel/e1nzqh5-0001ob...@fencepost.gnu.org

Best,
Ihor

Re: Org mode export accessibility

[T.V Raman]

briangpowell  writes:


P.S. Please dont quote me out of context. I did not say pdftex and
pdflatex were not useful, I still rely on them heavily.
> "[I suspect that the exported documents can similarly be improved to
> reduce the amount of effort required from visually impaired users to
> read
> such documents. The question is what improvements can be made on
> Org side.]
>
> Best,
> Ihor"
>
> Very glad to hear from TV Raman, the creator of EmacSpeak,
>
> I'm not blind like TV but I was motivated to turn my a main OrgMode
> buffer into an audio desktop like TV's
>
> But now back to the topic; much agree with Ihor, we should focus on
> "what improvements can be made on OrgMode side"
>
> & TV's points are well made too: "pdftex and pdflatex were built in
> the late 90's"--very true & they were rarely useful
>
> Suggest OrgMode make changes aimed at the "Lowest Common Denominator"
> of accessibility--accessibility in the visual sense AND in the machine
> or program processable sense or more exactly the "document convertible
> sense"--I mean documents should be made firstly in a form that all
> computers can easily navigate & present on computer screens and/or
> audio desktops in addition to being readily able to print out
>
> TV's right, the usual pipeline of LaTeX->PDF can produce tagged &
> useful documents but can an end user easily copy and paste the
> document? How useful are pretty documents that run on proprietary
> systems? Many PDF's can make simple processes like this very hard or
> impossible--the documents can be very pretty but they can contain
> control characters & special characters & even malicious code
>
> Suggest OrgMode outputs focus on creating "Lowest Common Denominator"
> documents as output:
> TeXinfo docs should be used as the LCD doctype--suggest you focus on
> creating 1 document in Texinfo that you use to create all other sorts
> of documents, when possible:
>
> Pipeline should be more like
> OrgMode->Texinfo->TROFF||DTD/XML/HTML/XHTML->LaTeX/TeX->DVI||SVG->PS->PDF
>
>
> * TeXinfo: https://savannah.gnu.org/projects/texinfo
> https://www.gnu.org/software/texinfo
>
> ** "Texinfo uses a single source file to produce output in a number of
> formats, both online and printed (dvi, html, info, pdf, xml, etc.).
> This means that instead of writing different documents for online
> information and another for a printed manual, you need write only one
> document.  And when the work is revised, you need revise only that one
> document.  The Texinfo system is integrated well with GNU Emacs. 
>
> *** Texinfo docs can also be viewed & used by ALL end-users without
> any issues--regardless of the power of their computer or monitor or
> even if they're blind like TV Raman--he uses an audio desktop or
> EmacSpeak--and the same docs can be printed on any printer & remain
> navigable with "rn" & other simple news-reading software--or the
> "info" program
>
> * Output formats currently supported by Texinfo:
> https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Output-Formats.html
> <=> Info,Text,HTML,DVI,PostScript{PS},PDF,DocBook,XML
>
> ** Related/useful may be: "latex2nemeth"--a LATEX to Braille/Nemeth,
> approach "Simple pictures in PSTricks are also supported in order to
> produce tactile graphics": https://ctan.org/pkg/latex2nemeth
>
> On Thu, Jun 30, 2022 at 3:53 AM Ihor Radchenko 
> wrote:
>
> "T.V Raman"  writes:
>
> > 1. Accessibility as word used in isolation has now become mostly
> >meaningless, to be concrete one has to ask "Accessibility to
> whom"? 
> >
> > 2. So in the following, everything I say is with respect to
> users with
> >visual impairments.
>
> This is exactly the perspective I was hoping to hear from you.
> Though
> this thread is not dedicated to visual impairments. (I guess you
> also
> did not touch the question of color blindness).
>
> > 3. It's incorrect to define "Accessibility" in terms of a
> specific
> >user access tool or technology -- that usage is marketing
> jargon
> >for a specific Access Solution like a screenreader --- so I
> refrain in general from
> >defining this in terms of Screenreaders.
>
> Yet, in order to simplify the efforts needed to read a document
> exported
> from Org mode one needs to use some kind of tool/technology.
> Unless a
> common standard exist in this area, we have to support at least
> the most
> common Access Solutions (prioritizing Free software, if possible).
>
> From you message, it does not look like there is any common
> standard.
>
> > With those meta-thoughts out of the way:
> >
> > A: Org-generated documents are mostly well-structured documents,
> and ...
> > B: The LaTeX->PDF pipeline *can* produce tagged PDF with respect
> to ...
> > C: pdftex and pdflatex were built in the late 90's by a student
> in ...
> > D: All that said, it is likely still 

Re: Org mode export accessibility

[T.V Raman]

P.S. Emacspeak is not camel-cased -- please say Emacspeak -- and not
with the 's' capitalized.
-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

Re: Org mode export accessibility

[T.V Raman]

On org side:

1. During authoring, ensure that authors have the ability to label
   images, drawings and math content.
   2. When exporting, make sure that that information gets through to
  the exported format.
  3. For math especially, make sure the TeX/LaTeX is preserved one
 way  or the other in the export

That's just a few initial thoughts, am sure there could be morebriangpowell 
writes:
 > "[I suspect that the exported documents can similarly be improved to
 > reduce the amount of effort required from visually impaired users to read
 > such documents. The question is what improvements can be made on
 > Org side.]
 > 
 > Best,
 > Ihor"
 > 
 > Very glad to hear from TV Raman, the creator of EmacSpeak,
 > 
 > I'm not blind like TV but I was motivated to turn my a main OrgMode buffer
 > into an audio desktop like TV's
 > 
 > But now back to the topic; much agree with Ihor, we should focus on "what
 > improvements can be made on OrgMode side"
 > 
 > & TV's points are well made too: "pdftex and pdflatex were built in the
 > late 90's"--very true & they were rarely useful
 > 
 > Suggest OrgMode make changes aimed at the "Lowest Common Denominator" of
 > accessibility--accessibility in the visual sense AND in the machine or
 > program processable sense or more exactly the "document convertible
 > sense"--I mean documents should be made firstly in a form that all
 > computers can easily navigate & present on computer screens and/or audio
 > desktops in addition to being readily able to print out
 > 
 > TV's right, the usual pipeline of LaTeX->PDF can produce tagged & useful
 > documents but can an end user easily copy and paste the document? How
 > useful are pretty documents that run on proprietary systems? Many PDF's can
 > make simple processes like this very hard or impossible--the documents can
 > be very pretty but they can contain control characters & special characters
 > & even malicious code
 > 
 > Suggest OrgMode outputs focus on creating "Lowest Common Denominator"
 > documents as output:
 > TeXinfo docs should be used as the LCD doctype--suggest you focus on
 > creating 1 document in Texinfo that you use to create all other sorts of
 > documents, when possible:
 > 
 > Pipeline should be more like
 > OrgMode->Texinfo->TROFF||DTD/XML/HTML/XHTML->LaTeX/TeX->DVI||SVG->PS->PDF
 > 
 > * TeXinfo: https://savannah.gnu.org/projects/texinfo
 > https://www.gnu.org/software/texinfo
 > 
 > ** "Texinfo uses a single source file to produce output in a number of
 > formats, both online and printed (dvi, html, info, pdf, xml, etc.). This
 > means that instead of writing different documents for online information
 > and another for a printed manual, you need write only one document.  And
 > when the work is revised, you need revise only that one document.  The
 > Texinfo system is integrated well with GNU Emacs.
 > 
 > *** Texinfo docs can also be viewed & used by ALL end-users without any
 > issues--regardless of the power of their computer or monitor or even if
 > they're blind like TV Raman--he uses an audio desktop or EmacSpeak--and the
 > same docs can be printed on any printer & remain navigable with "rn" &
 > other simple news-reading software--or the "info" program
 > 
 > * Output formats currently supported by Texinfo:
 > https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Output-Formats.html
 > <=> Info,Text,HTML,DVI,PostScript{PS},PDF,DocBook,XML
 > 
 > ** Related/useful may be: "latex2nemeth"--a LATEX to Braille/Nemeth,
 > approach "Simple pictures in PSTricks are also supported in order to
 > produce tactile graphics": https://ctan.org/pkg/latex2nemeth
 > 
 > On Thu, Jun 30, 2022 at 3:53 AM Ihor Radchenko  wrote:
 > 
 > > "T.V Raman"  writes:
 > >
 > > > 1. Accessibility as word used in isolation has now become mostly
 > > >meaningless, to be concrete one has to ask "Accessibility to whom"?
 > > >
 > > > 2. So in the following, everything I say is with respect to users with
 > > >visual impairments.
 > >
 > > This is exactly the perspective I was hoping to hear from you. Though
 > > this thread is not dedicated to visual impairments. (I guess you also
 > > did not touch the question of color blindness).
 > >
 > > > 3. It's incorrect to define "Accessibility" in terms of a specific
 > > >user access tool or technology -- that usage is marketing jargon
 > > >for a specific Access Solution like a screenreader --- so I refrain
 > > in general from
 > > >defining this in terms of Screenreaders.
 > >
 > > Yet, in order to simplify the efforts needed to read a document exported
 > > from Org mode one needs to use some kind of tool/technology. Unless a
 > > common standard exist in this area, we have to support at least the most
 > > common Access Solutions (prioritizing Free software, if possible).
 > >
 > > From you message, it does not look like there is any common standard.
 > >
 > > > With those meta-thoughts out of the way:
 > > >
 > > > A: Org-generated

Re: Org mode export accessibility

[briangpowell]

"[I suspect that the exported documents can similarly be improved to
reduce the amount of effort required from visually impaired users to read
such documents. The question is what improvements can be made on
Org side.]

Best,
Ihor"

Very glad to hear from TV Raman, the creator of EmacSpeak,

I'm not blind like TV but I was motivated to turn my a main OrgMode buffer
into an audio desktop like TV's

But now back to the topic; much agree with Ihor, we should focus on "what
improvements can be made on OrgMode side"

& TV's points are well made too: "pdftex and pdflatex were built in the
late 90's"--very true & they were rarely useful

Suggest OrgMode make changes aimed at the "Lowest Common Denominator" of
accessibility--accessibility in the visual sense AND in the machine or
program processable sense or more exactly the "document convertible
sense"--I mean documents should be made firstly in a form that all
computers can easily navigate & present on computer screens and/or audio
desktops in addition to being readily able to print out

TV's right, the usual pipeline of LaTeX->PDF can produce tagged & useful
documents but can an end user easily copy and paste the document? How
useful are pretty documents that run on proprietary systems? Many PDF's can
make simple processes like this very hard or impossible--the documents can
be very pretty but they can contain control characters & special characters
& even malicious code

Suggest OrgMode outputs focus on creating "Lowest Common Denominator"
documents as output:
TeXinfo docs should be used as the LCD doctype--suggest you focus on
creating 1 document in Texinfo that you use to create all other sorts of
documents, when possible:

Pipeline should be more like
OrgMode->Texinfo->TROFF||DTD/XML/HTML/XHTML->LaTeX/TeX->DVI||SVG->PS->PDF

* TeXinfo: https://savannah.gnu.org/projects/texinfo
https://www.gnu.org/software/texinfo

** "Texinfo uses a single source file to produce output in a number of
formats, both online and printed (dvi, html, info, pdf, xml, etc.). This
means that instead of writing different documents for online information
and another for a printed manual, you need write only one document.  And
when the work is revised, you need revise only that one document.  The
Texinfo system is integrated well with GNU Emacs.

*** Texinfo docs can also be viewed & used by ALL end-users without any
issues--regardless of the power of their computer or monitor or even if
they're blind like TV Raman--he uses an audio desktop or EmacSpeak--and the
same docs can be printed on any printer & remain navigable with "rn" &
other simple news-reading software--or the "info" program

* Output formats currently supported by Texinfo:
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Output-Formats.html
<=> Info,Text,HTML,DVI,PostScript{PS},PDF,DocBook,XML

** Related/useful may be: "latex2nemeth"--a LATEX to Braille/Nemeth,
approach "Simple pictures in PSTricks are also supported in order to
produce tactile graphics": https://ctan.org/pkg/latex2nemeth

On Thu, Jun 30, 2022 at 3:53 AM Ihor Radchenko  wrote:

> "T.V Raman"  writes:
>
> > 1. Accessibility as word used in isolation has now become mostly
> >meaningless, to be concrete one has to ask "Accessibility to whom"?
> >
> > 2. So in the following, everything I say is with respect to users with
> >visual impairments.
>
> This is exactly the perspective I was hoping to hear from you. Though
> this thread is not dedicated to visual impairments. (I guess you also
> did not touch the question of color blindness).
>
> > 3. It's incorrect to define "Accessibility" in terms of a specific
> >user access tool or technology -- that usage is marketing jargon
> >for a specific Access Solution like a screenreader --- so I refrain
> in general from
> >defining this in terms of Screenreaders.
>
> Yet, in order to simplify the efforts needed to read a document exported
> from Org mode one needs to use some kind of tool/technology. Unless a
> common standard exist in this area, we have to support at least the most
> common Access Solutions (prioritizing Free software, if possible).
>
> From you message, it does not look like there is any common standard.
>
> > With those meta-thoughts out of the way:
> >
> > A: Org-generated documents are mostly well-structured documents, and ...
> > B: The LaTeX->PDF pipeline *can* produce tagged PDF with respect to ...
> > C: pdftex and pdflatex were built in the late 90's by a student in ...
> > D: All that said, it is likely still easier to go from org->HTML ...
>
> Do I understand correctly that you have no issues with reading documents
> exported using current version of Org?
>
> > E: Finally, note that in (D) I said "machine processable" not
> > "Accessible"; machine-processable is a pre-requisite to "repurpose "
> > what you publish, and making  that result usable by different user
> > communities is a direct consequence of suche machine-processability.
>
> I understand. Bu

Re: Org mode export accessibility

[Ihor Radchenko]

"T.V Raman"  writes:

> 1. Accessibility as word used in isolation has now become mostly
>meaningless, to be concrete one has to ask "Accessibility to whom"? 
>
> 2. So in the following, everything I say is with respect to users with
>visual impairments.

This is exactly the perspective I was hoping to hear from you. Though
this thread is not dedicated to visual impairments. (I guess you also
did not touch the question of color blindness).

> 3. It's incorrect to define "Accessibility" in terms of a specific
>user access tool or technology -- that usage is marketing jargon
>for a specific Access Solution like a screenreader --- so I refrain in 
> general from
>defining this in terms of Screenreaders.

Yet, in order to simplify the efforts needed to read a document exported
from Org mode one needs to use some kind of tool/technology. Unless a
common standard exist in this area, we have to support at least the most
common Access Solutions (prioritizing Free software, if possible).

>From you message, it does not look like there is any common standard.

> With those meta-thoughts out of the way:
>
> A: Org-generated documents are mostly well-structured documents, and ...
> B: The LaTeX->PDF pipeline *can* produce tagged PDF with respect to ...
> C: pdftex and pdflatex were built in the late 90's by a student in ...
> D: All that said, it is likely still easier to go from org->HTML ...

Do I understand correctly that you have no issues with reading documents
exported using current version of Org?

> E: Finally, note that in (D) I said "machine processable" not
> "Accessible"; machine-processable is a pre-requisite to "repurpose "
> what you publish, and making  that result usable by different user
> communities is a direct consequence of suche machine-processability.

I understand. But one can similarly say that .org files are "machine
processable" and Org export code is not strictly necessary. Yet, it ends
up extremely useful in practice.

I suspect that the exported documents can similarly be improved to
reduce the amount of efforts required from visually impair users to read
such documents. The question is what kinds improvements can be made on
Org side.

Best,
Ihor

Re: Org mode export accessibility

[T.V Raman]

Thanks for looping me in.
I'm not subscribed to emacs-orgmode --- so feel free to forward if you
find the thoughts below materially useful.

As  a long-term org-mode user --- and an even  longer  term TeX
user: here are some thoughts:

1. Accessibility as word used in isolation has now become mostly
   meaningless, to be concrete one has to ask "Accessibility to whom"? 

2. So in the following, everything I say is with respect to users with
   visual impairments.

3. It's incorrect to define "Accessibility" in terms of a specific
   user access tool or technology -- that usage is marketing jargon
   for a specific Access Solution like a screenreader --- so I refrain in 
general from
   defining this in terms of Screenreaders.

With those meta-thoughts out of the way:

A: Org-generated documents are mostly well-structured documents, and
not in general a user-interface e.g. (WebApp); so  with regard to export --
either HTML or LaTeX/PDF ---  ARIA is mostly irrelevant.

B: The LaTeX->PDF pipeline *can* produce tagged PDF with respect to
document structure eg. Sectioning, but only if you use pdflatex or
pdftex i.e. LaTeX/Tex->dvi->[ps]->pdf is lossy with respect to
structure present in the markup; this is a short-coming of DVI which
predates  the thought of document structure making it through to the
output.

C: pdftex and pdflatex were built in the late 90's by a student in
Prague (Hanu Than? from memory) --- only reason I know this is that I
got Adobe to fund that project when at Adobe in the 90's. It's a very
good piece of work that essentially uses PDF directly as the "Device
Independent" format rather than the original dvi. DVI as designed in
the 70's was device-independent for the time, ie it did not hardwire
printer controls and could be mapped to various print mechanisms. For
the 90s, by which time Document Structure meant a lot more than being
some version of inkjet printer driver independent, the afore mentioned
project used PDF as the Device-Independent format --- and
leveraged the Tagged PDF bits from PDF 1.4 to achieve the result.

D: All that said, it is likely still easier to go from org->HTML
directly and produce content that is easier to machine-process  ---
rather than go through one more level of indirection via LaTeX and
PDF; however there may well be additional constraints in a publication
workflow, e.g. publisher wants to only publish final-form -- and yes,
in this case, HTML and PDF are both final-form.

E: Finally, note that in (D) I said "machine processable" not
"Accessible"; machine-processable is a pre-requisite to "repurpose "
what you publish, and making  that result usable by different user
communities is a direct consequence of suche machine-processability.


Hope this helps.

-- 
--Raman 
Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

--

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
♉ Id: kg:/m/0285kf1  🦮

Re: Org mode export accessibility

[Ihor Radchenko]

Let me take a freedom to add T.V Raman to the discussion. This thread
might be of interest for him and he probably knows a lot more about
accessibility options.

This thread starts at
https://list.orgmode.org/87v8sn3obd@gmail.com/T/#u

Juan Manuel Macías  writes:

> Tim Cross writes:
>
>> As I understand it (which isn't brilliant), the core problem is more to
>> do with how the LaTeX/TeX engine processes the input to generate the
>> postscript and pdf output. Modern PDFs have a wealth of internal tagging
>> which simply sin't supported via the tex -> pdf pathway. The matter is
>> made slightly worse by a lack of built-in support within latex/tex for
>> accessibility 'tags' (similar to the aria tags for web content). 
>
> There is a relatively recent experimental package for LaTeX that may be
> of interest to you:
>
> CTAN: https://www.ctan.org/pkg/tagpdf
>
> GitHub: https://github.com/u-fischer/tagpdf
>
> The package is maintained by Ulrike Fischer, who is very active in the
> TeX community. However, the package description says:
>
>> The package offers tools to experiment with tagging and accessibility
>> using pdfLaTeX and LuaTeX. It isn't meant for production but allows
>> the user to try out how difficult it is to tag some structures; to try
>> out how much tagging is really needed; to test what else is needed so
>> that a pdf works e.g. with a screen reader. Its goal is to get a
>> feeling for what has to be done, which kernel changes are needed, how
>> packages should be adapted.
>
> Best regards,
>
> Juan Manuel 

Re: Org mode export accessibility

[Juan Manuel Macías]

Tim Cross writes:

> As I understand it (which isn't brilliant), the core problem is more to
> do with how the LaTeX/TeX engine processes the input to generate the
> postscript and pdf output. Modern PDFs have a wealth of internal tagging
> which simply sin't supported via the tex -> pdf pathway. The matter is
> made slightly worse by a lack of built-in support within latex/tex for
> accessibility 'tags' (similar to the aria tags for web content). 

There is a relatively recent experimental package for LaTeX that may be
of interest to you:

CTAN: https://www.ctan.org/pkg/tagpdf

GitHub: https://github.com/u-fischer/tagpdf

The package is maintained by Ulrike Fischer, who is very active in the
TeX community. However, the package description says:

> The package offers tools to experiment with tagging and accessibility
> using pdfLaTeX and LuaTeX. It isn't meant for production but allows
> the user to try out how difficult it is to tag some structures; to try
> out how much tagging is really needed; to test what else is needed so
> that a pdf works e.g. with a screen reader. Its goal is to get a
> feeling for what has to be done, which kernel changes are needed, how
> packages should be adapted.

Best regards,

Juan Manuel 

Re: Org mode export accessibility (was: About 'inline special blocks')

[Tim Cross]

Ihor Radchenko  writes:

> Tim Cross  writes:
>
>> Sadly, org isn't great from an accessibility perspective. This is
>> something I would like to see improved, but it is a huge and complex
>> task. There are some 'easy' winds we could try. For example, org still
>> defaults to using the  and  tags instead of
>>  and . Likewise, we should move to html5 as
>> the default, not xhtml, but last time I raised that, there was
>> considerable push back to stick with xhtml. We also need complete
>> overhaul of the use of aria tags and numerous other areas. As I said, a
>> very large job which is complex and extremely time consuming. 
>
> I will not argue about html5 switch - I don't have enough knowledge to
> weigh on this.
>
> However, can't we at least address accessibility issues with the
> existing HTML export? A good starting point could be identifying what
> can be improved in ox-html.el.
>

Yes, we can probably make some incremental improvements. However, it is
a complex and difficult area and I suspect to really improve the
situation, we likely need a major re-design. A big part of the challenge
is how to enable authors to add the right level of accessibility
'tagging', but at the same time, not lose one of the main advantages of
org mode i.e. simplicity and ease of syntax. 

>> Sadly, I'm not sure there is a lot we can do with accessibility and PDFs
>> in org mode. This is the one area where TeX/LaTeX does a poor job. Last
>> time I looked, there was considerable discussion about what to do from
>> an accessibility standpoint in the TeX community, but seemed to be
>> little or very slow progress (not a criticism of the efforts of members
>> of that community, but rather a reflection of how complicated this stuff
>> is).
>
> From Org perspective, we can do what is available in the exported
> format. If LaTeX is not great from accessibility point of view, is there
> a better format? Or are there things we can do to improve situation in
> ox-latex.el?
>

As I understand it (which isn't brilliant), the core problem is more to
do with how the LaTeX/TeX engine processes the input to generate the
postscript and pdf output. Modern PDFs have a wealth of internal tagging
which simply sin't supported via the tex -> pdf pathway. The matter is
made slightly worse by a lack of built-in support within latex/tex for
accessibility 'tags' (similar to the aria tags for web content). 

> What about other export backends?
>

To be honest, no idea. I'm certainly not an expert in these areas. While
I am impacted more by lack of accessibility, unfortunately, that doesn't
make you an expert.

I do feel that in order to get reasonable accessibility levels, it is
probably something which needs to be baked in as part of the overall
design and not something which can be added later. This isn't really
feasible. Things can probably be slightly improved, but I doubt org mode
and the documents it produces will ever be particularly good from an
accessibility perspective. 

Org mode export accessibility (was: About 'inline special blocks')

[Ihor Radchenko]

Tim Cross  writes:

> Sadly, org isn't great from an accessibility perspective. This is
> something I would like to see improved, but it is a huge and complex
> task. There are some 'easy' winds we could try. For example, org still
> defaults to using the  and  tags instead of
>  and . Likewise, we should move to html5 as
> the default, not xhtml, but last time I raised that, there was
> considerable push back to stick with xhtml. We also need complete
> overhaul of the use of aria tags and numerous other areas. As I said, a
> very large job which is complex and extremely time consuming. 

I will not argue about html5 switch - I don't have enough knowledge to
weigh on this.

However, can't we at least address accessibility issues with the
existing HTML export? A good starting point could be identifying what
can be improved in ox-html.el.

> Sadly, I'm not sure there is a lot we can do with accessibility and PDFs
> in org mode. This is the one area where TeX/LaTeX does a poor job. Last
> time I looked, there was considerable discussion about what to do from
> an accessibility standpoint in the TeX community, but seemed to be
> little or very slow progress (not a criticism of the efforts of members
> of that community, but rather a reflection of how complicated this stuff
> is).

>From Org perspective, we can do what is available in the exported
format. If LaTeX is not great from accessibility point of view, is there
a better format? Or are there things we can do to improve situation in
ox-latex.el?

What about other export backends?

Best,
Ihor