From: Tim Cross <theophilusx@gmail.com>
To: Mario Lang <mlang@blind.guru>
Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: Request for partecipating in the project
Date: Tue, 24 Dec 2019 01:38:41 +1100 [thread overview]
Message-ID: <CAC=50j_WRwuy0+He1WQLW4yiDjoKxo01QkNvojwKNeNJt01wfw@mail.gmail.com> (raw)
In-Reply-To: <87woanlfcf.fsf@blind.guru>
[-- Attachment #1: Type: text/plain, Size: 3763 bytes --]
epub is an HTML based format. Essentially it is an archive file of HTML and
metadata. So the issue isn't so much whether it is better than HTML but
more about some of the tools available. Most ebook reader applications are
designed to optimize reading of books - they usually make moving
back/forward in 'pages' easier, have consistent access to table of
contents, allow easy setting of font types, sizes and color etc. For
example, I find epub works far better with VoiceOver (the text-to-speech
application in macOS, ipdaOS and IOS) on macOS, ipadOS and IOS than does
either Safari (for HTML) or PDF (with any of the available PDF viewers like
Preview or Adobe etc) for reading books. Likewise, the Kindle app on macOS,
ipadOS or IOS works really well with voiceOver. The web based Kindle app is
not accessible at all.
As Raman points out, texinfo under Emacs and .info files are very
accessible thanks to packages like his Emacspeak or others like
speechd.el. However, other formats generated from Texinfo sources are less
so. For PDF the issue is that TeX/Latex PDF generation tools are very poor
at creating accessible PDF documents (this has been acknowledge within the
TeX/Latex community and there has been some work to improve the situation,
but the changes required are non-trivial and progress is slow).
It has been some time since I looked at HTML documents generated from
texinfo, but when I last checked, the accessibility was not great
(accessibility to documents is not a binary proposition - some documents
are sort of accessible, but lack appropriate tags/labels to make navigation
of the documents 'make sense', so you might be able to get parts of the
document read out, but being able to effectively navigate the document and
find what you want is difficult or the data is presented 'out of sequence'
compared to how a sighted person would see it).
For me, the advantage of having Emacs documentation in one of these other
ebook formats is that it could make it possible to access this
documentation outside of Emacs. I find this quite useful. For example, when
working on a project, I might open reference books on my ipad or iphone
while working in Emacs on macOS or GNU Linux. I find it is sometimes more
convenient to check things on the ipad rather than switching buffers/frames
under Emacs. I can also use apps that will read epub (or other formats)
continuously, which is handy when doing boring tasks like hanging out the
washing - Today, I was listening to 'Elements of Clojure' while hanging
out the washing.
the point of my earlier post was that the generation of documents in other
formats, like an ebook, from texinfo sources is unlikely to be that
accessible without a fair bit of effort. I have had good success with
Calibre for other document types, but it did take a fair bit of tweaking
and experimentation. Having the Emacs documentation in ebook formats would
likely be useful to many people, but getting a decent conversion may be
challenging and getting an accessible version even more so. I do think it
is important to be able to generate the output from existing texinfo files
i.e. don't want to have 2 versions of the documents as we will never keep
them 'in sync'.
On Mon, 23 Dec 2019 at 17:34, Mario Lang <mlang@blind.guru> wrote:
> Tim Cross <theophilusx@gmail.com> writes:
>
> > One of the advantages of some ebook formats, such as epub, is that they
> can
> > be more accessible for the blind and vision impaired than PDF or even
> HTML.
>
> Please name an example where epub clearly is bettern then HTML.
> I (a blind user) have never seen one until now.
>
> --
> CYa,
> ⡍⠁⠗⠊⠕
>
--
regards,
Tim
--
Tim Cross
[-- Attachment #2: Type: text/html, Size: 4338 bytes --]
next prev parent reply other threads:[~2019-12-23 14:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-22 21:38 Request for partecipating in the project arthur miller
2019-12-22 22:00 ` Marcin Borkowski
2019-12-23 0:03 ` Tim Cross
2019-12-23 1:50 ` arthur miller
2019-12-23 3:23 ` T.V Raman
2019-12-23 6:34 ` Mario Lang
2019-12-23 14:38 ` Tim Cross [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-12-23 16:04 arthur miller
2019-12-23 16:43 ` Tim Cross
2019-12-23 17:19 ` T.V Raman
2019-12-22 22:32 arthur miller
2019-12-22 22:46 ` Marcin Borkowski
2019-12-22 17:23 Sam Qasbah
2019-12-24 4:13 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAC=50j_WRwuy0+He1WQLW4yiDjoKxo01QkNvojwKNeNJt01wfw@mail.gmail.com' \
--to=theophilusx@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=mlang@blind.guru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.