From: Samuel Thibault <sthibault@debian.org>
To: Till Kamppeter <till.kamppeter@gmail.com>
Cc: printing-architecture@lists.linux-foundation.org,
Adam Chester <adam.chester@pentest.co.uk>,
Debian-printing@lists.debian.org,
Yann Soubeyrand <yann-externe.soubeyrand@edf.fr>
Subject: Re: [Printing-architecture] documents and braille [Was: cups-filters 1.4.0 released!]
Date: Mon, 21 Dec 2015 15:25:36 +0100 [thread overview]
Message-ID: <20151221142536.GG12316@var> (raw)
In-Reply-To: <5677F4DF.6080601@gmail.com>
Hello,
Till Kamppeter, on Mon 21 Dec 2015 10:47:27 -0200, wrote:
> First, I would not call the two modes "ink" and "braille", but something
> like "Original layout" and "Braille-optimized layout".
Ok.
> Second, LibreOffice does not send .odt files when clicking "Print" in the
> print dialog. By default it sends PDF, and in the settings you can switch it
> to PostScript, but there is always one of these two formats selected for all
> printers.
I know, that's precisely what I'd like to see optionally changed.
> At least the PDF sent by LibreOffice is not a bitmap of each page, but it
> contains the (searchable) text and instructions for formatting and layout
> (high-level/vector graphics), similar to what the .odt file contains. So it
> should be possible to extract the text and formatting and re-arrange it for
> the Braille output (as e-book readers can do it with PDFs or the "reflow"
> mode of the Adobe Reader on Android).
I know, but that's extremely far from optimal: the structure is nicely
encoded inthe odt file, while finding it out from the pdf file is at
*best* a pain, and will not allow proper reformatting such as putting
footnotes at the bottom of pages, renumbering page references, etc.
> I also doubt whether the LibreOffice developers would implement a feature
> request of sending print data in .odt format,
I don't see why: this doesn't seem like a hard feature to implement.
Another way would have been to emit an epub or a daisy document but
that's way more involved, I wouldn't try to ask for this.
> but I would rather believe in that they would implement a
> feature request in giving optimizing options for the PDF of the
> print output, for example for e-book reader/braille embosser
> text-reflow-friendliness.
This feature request is actually already pending, since this is
equivalent to the general accessibility of PDF files. This is however
still quite far from optimal, I would really not bet on this on the long
run.
Samuel
prev parent reply other threads:[~2015-12-21 14:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <566F564D.9040000@gmail.com>
[not found] ` <20151215000648.GK2967@var.home>
[not found] ` <566F66B8.4060106@gmail.com>
[not found] ` <20151220235820.GU4287@var.home>
2015-12-21 12:47 ` [Printing-architecture] documents and braille [Was: cups-filters 1.4.0 released!] Till Kamppeter
2015-12-21 14:25 ` Samuel Thibault [this message]
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=20151221142536.GG12316@var \
--to=sthibault@debian.org \
--cc=Debian-printing@lists.debian.org \
--cc=adam.chester@pentest.co.uk \
--cc=printing-architecture@lists.linux-foundation.org \
--cc=till.kamppeter@gmail.com \
--cc=yann-externe.soubeyrand@edf.fr \
/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.
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.