Customizable Print Formats GSoC 2015

[Lubomir I. Ivanov]

On 4 March 2015 at 13:39, Robert Helling <helling at atdotde.de> wrote:
> Hi,
>
> On 03.03.2015, at 13:05, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>
> i think, before you start writing the proposal users should provide
> feedback on what level of customization they want from the print
> layouting.
> Davide, Robert - any ideas?
>
>
> I think my old comments still apply: Typesetting is a highly non-trivial
> task (in particular if your expectations are more than basic), even decent
> line breaks are not easy to get let alone more complex formatting tasks. I
> think it would be foolish to attempt to set it up from scratch. Even without
> templates/user definable layout we currently fail miserable in this task. To
> my mind, we need to rely on external tools (library or program) to produce
> decent output on a printer. Setting things up by putting text in some
> rectangles will not do. For similar reasons, I don’t think html is the way
> to go since it is designed to render on screens rather than sheets of paper.
> You only need to look at the current gymnastics we do not to run over the
> bottom of the sheet. To me, doing proper typesetting is the hard part,
> making this configurable (for example with templates) is then secondary.

i agree, it's quite complicated of a task and it can end up being a huge mess.
also i get a feeling that Qt introduced more complications than what
we had with the old Cairo print rendering in terms of page wrapping
and inconsistencies.
some of the code i've added in PrintLayout doesn't make much sense -
so this is a "can of worms" opener for sure!

for me, it's tempting to experiment with CSS + HTML and try to render
say the output of a QWebPage widget (i bet it will be slow as hell).
if we present the user with a simple CSS / HTML input UI and a set of
predefined layouts and predefined variables (DIVE_LOCATION, BUDDIES,
etc) and we can use a parser to replace those with actual values from
"struct dive". that was part of my original idea when the discussion
started an year ago or so.

also, i don't understand Tomaz' idea about the Grantlee extension, so
perhaps we need to investigate into that as well.
it probably uses QTableView Qt's Model-View-X pattern, which i don't
like that much, yet Subsurface already uses it pretty much everywhere!

>
> One way to go would be to pipe into LibreOffice writer (to use other open
> source software) and rely on it’s abilities to turn strings of characters
> and tables into decent pdf. But I don’t think this is very elegant (and it
> will without doubt be painful).
>
> I would like to argue once more to use TeX as the typesetting engine (I have
> done so in the past).
>
> There is one obvious downside of this: Joe Average User (probably everybody
> outside academia) does not have TeX installed and with all its fonts and
> utilities it is a huge software package. And this is why this proposal was
> turned down in the past.
>

i'm(/was) very fond of TeX idea, but it's like big packages like
Matlab, Maxima - it's very capable but makes your distribution
non-self contained, compared to a C package that does the calculation.
also, yes 99% of the users will not have TeX installed, so we need
make this optional.

we could go with this if others agree:
- keep the current printer scheme
- support TeX export as the alternative for advanced users

so in a way, if one *really* demands sophisticated hardcopies he/she
should use the LaTeX export.
one problem with this approach is that we do not bridge the gap
between the average and advanced user.

> But please, let me one last time argue its pros:
>
> o) Even though it is not installed, it is not that hard to install. Packages
> exists essentially for all platforms, it is just one dependency (for pdftex)
> on any Linux package manager, there are ready to install (single click)
> packages for Windows and Mac. And is probably the prime example of
> stability: Since the mid-1980s every TeX source as produced exactly the same
> output only any platform. Version problems are nonexistent (thanks to the
> stubbornness of Don Knuth).
>
> o) As it is an external program, we don’t need to force it on users. Only
> those users who want to use subsurface to produce prime quality paper
> logbook pages would need to install it.
>
> o) Typesetting quality is second to none (as a lot of research has gone into
> it)
>
> o) Its input is very simple, in that respect it is similar to html (ascii as
> input format).
>
> o) As such it is trivial to use with any templating solution. In fact, since
> it is a macro language, it already comes with this.
>
> To illustrate, I attached a patch that adds a simple prototype of
> TeX-printing to current master (I actually use this to produce my paper log
> from subsurface).
>
>
> It does nothing unless you have “pdftex” in your path. If you do, it adds
> one point to the dive-list context menu, which typesets the current dive
> into a pdf. All layout is done in logbookstyle.tex which plays the role of a
> template. All subsurface has to do is to output a file dive.tex that in my
> case contains just
>
> \def\date{2014-11-15}
> \def\number{476}
> \def\place{Allmanshausen, Badeplatz}
> \def\spot{}
> \def\country{}
> \def\entrance{}
> \def\time{44:00}
> \def\depth{30.7m}
> \def\gasuse{}
> \def\sac{16.7 l/min}
> \def\type{}
> \def\viz{3}
> \def\plot{\includegraphics[width=9cm,height=4cm]{profile}}
> \def\comment{Vytec Batterie nicht richtig eingesetzt, zwei Weihnachtsmänner,
> riesiger Barschschwarm beim Auftauchen (11m), trotz Terminverpeilung durfte
> ich mittauchen. Wassereinbruch oben am Reissverschluss, hervorgerufen durch
> fehlerhafte Klebung.}
> \def\buddy{Gernot, Hanah Ewa}
> \input logbookstyle
>
> to produce
>
> .
>
> Yes, it’s huge, but I doubt you will get anything with comparable output
> quality at a much lighter weight.
>

on Windows pdftext can be downloaded as a separate 15mb package, but
of course it's broken without extra work to figure out how to install
it properly. :-(
the big (e.g. >150mb) TeX distributions AFAIK work, but i haven't
tried one in a while.

but with this we can potentially discard all the hard work needed to
implement templates and so on and add this as an export instead (e.g.
"Export TeX for selected dives") and even rename the GSoC task; then
tell advanced users to use this export if they demand more complicated
hardcopies.

a good option and it's less work for me, so it gets a +1 (i think, i
said the same when you proposed that last time).
but it's up to Dirk and the userbase to decide and provide more
feedback and ideas.

lubomir
--