On 08/12/2011 10:00 PM, Raphael Hertzog wrote:
Hi,
On Fri, 12 Aug 2011, Jeff Fearn wrote:
Foot notes become end notes
This is rather annoying. On a HTML page you can click the link and use the
back button. On a printed copy you can forget this...
It's not nearly as annoying as the limitations FOP has, such as no
complex text PDFs, and the fact that the current release is basically
un-packagable.
Pros:
Layout matches HTML
Layout synced with HTML
On Fri, 12 Aug 2011, Ryan Lerch wrote:
I love that there will only be 1 styling mechanism (CSS) across all
the 4 default outputs. Makes it much easier to create new, and
maintain styles.
This is good for us, but not necessarily for the reader. As a reader, I
don't have the same expectation from an HTML output and a PDF output.
The PDF and HTML outputs differing is one of the most common complaints
we get.
The PDF should be a high quality rendering so that the result is perfect
should it be printed as a real book (via a print-on-demand service for
example).
This was the original goal of the PDF, it was not attainable, and it is
not what PDF consumers use it for. The PDF is now aimed at being a
single file distributable, which closely resembles the other outputs.
Perhaps sometime in the future we will consider another output for this
use case.
On a page oriented document, a two column layout is often used but this
would never be used in HTML and is next to impossible to create AFAIK.
You can't do this now.
Also you how do you deal with stuff like page numbering and references to
page numbers? And having a differente layout for odd/even pages?
We don't support either of these ATM aside from a small page margin
change between odd and even pages.
On Fri, 12 Aug 2011, Jeff Fearn wrote:
Not Java
Fast
Not Java
Small memory footprint
Not Java
Maintainable
Not Java
I don't really like java either but IMO it should not be used as a reason to
switch to somethings with less features.
The reason we are switching is because FOP is unmaintainable, if you
want to step up and maintain FOP then I'm happy to stick with it. Unless
someone steps up and maintains FOP we will be looking to switch, even if
we lose some functionality.
Our time being wasted is sufficient reason for change.
Most of the people doing docbook use some sort of LaTeX based backend for
the PDF generation. And it's also what many people expect when it comes to
create a real book.
I've never seen any even remotely decent docbook->latex tools, feel free
to drop some names and some links if you know of any.
Why was FOP preferred over LaTeX?
At the time the Latex options sucked horribly for CJK, and Indic was
impossible with CJK support. FOP gave us the hope of having a single
tool that could handle all the languages required, a false hope as it
turned out :(
On 08/12/2011 01:03 PM, Joshua Wulf wrote:
This is because the test is using a patched QT, installed outside
the normal library path, and I modified the CSS file to break those
ways to see if it was easy to overcome such issues.
Urgh, this is the kind of stuff that distributors (like Debian) do not
like at all...
Yeah, Fedora is going to hate it too, but I'm not supporting FOP just
because other people don't like the alternatives. There is only a
certain amount of time we have to do stuff and FOP is a massive time
sink, unless people are going to help carry FOP we are definitely going
to switch if we find a usable alternative that sucks less time.
If it's much less featured, but sucks much less time, then that's a fair
trade AFAIAC.
Are those changes things that are upstreamable in QT/Webkit?
Apparently getting changes up-streamed is difficult in that community.
Cheers, Jeff.
_______________________________________________
publican-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/publican-list
Wiki: https://fedorahosted.org/publican
