- From: Kai Weber <sermo_de_arboribus@seznam.cz>
- Date: Thu, 07 Feb 2013 22:12:23 +0100 (CET)
- To: <public-ppl@w3.org>
- Message-Id: <6Jl.8JHW.7fHkoaMI8ta.1H51Yt@seznam.cz>
Hi Patrick, I saw your presentation on speedata publisher in Stuttgart around a year ago and was very interested in it. I got to download and try some first simple layout tasks, yet I was put off by not getting a multi-page textflow working... I see your concern is mostly to stuff a certain amount of information on one page, but I imagine your approach might have some advantages to cross-page flows. I believe speedata could do that, I just didn't figure out how... If discussion renews here I'll be happy to follow and might be enticed to give it another try... Best regards, Kai Weber " Am 07.02.2013 um 21:09 schrieb Patrick Gundlach <gundlach@speedata.de>: > Hello Tony and all others, > > I am a member of this list and thus part of the inactivity. I don't think _I_ need a new Chair, I think I need some more time for discussion. > > My business is in the "xml to pdf on paged media" area, so I have joined this list a few months ago. I have written an open source software and I'd like to share my approach with this list to get comments. > > I have waited until now, because every part of the documentation was still in German - and probably not of any help at all except for a few people here. Now the English translation is getting better and better (still 90% missing) and I think I can start collecting comments as the documentation gets updated. > > The kind of documents I deal with is product catalogs and other applications that need much optimization during the layout process. > > * Can we fit another product onto the page by rearranging the products that are already on the page? > * If we reduce the font size, we will be able to fit the text on one page. > * The tables and images should be positioned so that the text in all given languages easily fit in the place above the table/image. > > Many applications require dynamic layout optimization. > > The problem I see with XSL-FO is mostly that the layout is more or less fixed before rendering. It is hard to get information back from the renderer to the place where you decide on the actual layout of the page. Why is this a problem? If you have a chunk of text and you need to be sure that it has at most some given dimensions, you can only find out about the size of the text if you really typeset it. -- Now my approach is to interpret the layout instructions _inside_ the renderer so you can always ask the renderer to typeset something on a virtual page and find out about the exact dimension.. To do this, I have separated the layout instructions (XML) and the data XML file. > > The layout instruction file is a mixture of different kind of "standards" and some programming constructs. The table model stems from HTML, the access to the XML data is very similar to XPath (2.0), the node walking has a few similarities with XSL, we optionally use CSS for some elements (more will follow) and we have variables/loops and if-then-else conditionals. > > I have lots of ideas on how to improve the current limitations in my implementation, but the lack of time prohibits the complete implementation of all features above. For example the XPath support is limited to a few functions and a few operators yet, more will be included if I have time (and money) for that. > > Even with the limitations, my software is used in production for various clients, so I can promise that it is very usable, even with the mentioned unperfectness. > > I would like to hear any opinions on that matter. I'll be off to xmlprague friday-monday, and because of the big holes in the documentation it might be early to start this discussion now. But anyway, I just feel it's time for this email. > > Some background: I've implemented this in Lua and the backend is LuaTeX, a modern variant of TeX, the typsetting system. My software uses a special mode of LuaTeX in which I can write the PDF directly without generating any TeX code, but still take full advantage of the things TeX offers: great line breaking algorithm, font and image reading and other layout helpers (glue, boxes, ...) > > Now some links: > > The project page: http://speedata.github.com/publisher/ > Manual: http://speedata.github.com/publisher/manual/index.html > Github page: https://github.com/speedata/publisher > Installation instructions: https://github.com/speedata/publisher/wiki > Sample layout file: http://speedata.github.com/publisher/manual/examples/ en/planets/planets-layout.xml > The 'data file' for the layout above: http://speedata.github.com/ publisher/manual/examples/en/planets/planets-data.xml > > > Patrick > > > speedata UG (haftungsbeschränkt) > ------------------------------------- > Telefon 030/57705055 > Mobil 0178/1967142 > Mail gundlach@speedata.de > Web www.speedata.de > > Eisenacher Straße 101 > 10781 Berlin > ------------------------------------- > Amtsgericht Charlottenburg HRB 135360 B > Geschäftsführer: Patrick Gundlach > USt-IdNr: DE278023065 > > >"--=_49b135713df8e62f1aa6c128ñ57a000-99ab-533d-9ebd-9c1dfb9abc45_Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body>Hi Patrick,<br><br>I saw your presentation on speedata publisher in Stuttgart around a year ago and was very interested in it. I got to download and try some first simple layout tasks, yet I was put off by not getting a multi-page textflow working... I see your concern is mostly to stuff a certain amount of information on one page, but I imagine your approach might have some advantages to cross-page flows. I believe speedata could do that, I just didn't figure out how... If discussion renews here I'll be happy to follow and might be enticed to give it another try...<br><br>Best regards,<br><br>Kai Weber<br><br><blockquote><br>Am 07.02.2013 um 21:09 schrieb Patrick Gundlach <gundlach@speedata.de>:<br><br>> Hello Tony and all others,<br>> <br>> I am a member of this list and thus part of the inactivity. I don't think _I_ need a new Chair, I think I need some more time for discussion.<br>> <br>> My business is in the "xml to pdf on paged media" area, so I have joined this list a few months ago. I have written an open source software and I'd like to share my approach with this list to get comments.<br>> <br>> I have waited until now, because every part of the documentation was still in German - and probably not of any help at all except for a few people here. Now the English translation is getting better and better (still 90% missing) and I think I can start collecting comments as the documentation gets updated.<br>> <br>> The kind of documents I deal with is product catalogs and other applications that need much optimization during the layout process. <br>> <br>> * Can we fit another product onto the page by rearranging the products that are already on the page? <br>> * If we reduce the font size, we will be able to fit the text on one page.<br>> * The tables and images should be positioned so that the text in all given languages easily fit in the place above the table/image.<br>> <br>> Many applications require dynamic layout optimization.<br>> <br>> The problem I see with XSL-FO is mostly that the layout is more or less fixed before rendering. It is hard to get information back from the renderer to the place where you decide on the actual layout of the page. Why is this a problem? If you have a chunk of text and you need to be sure that it has at most some given dimensions, you can only find out about the size of the text if you really typeset it. -- Now my approach is to interpret the layout instructions _inside_ the renderer so you can always ask the renderer to typeset something on a virtual page and find out about the exact dimension. To do this, I have separated the layout instructions (XML) and the data XML file.<br>> <br>> The layout instruction file is a mixture of different kind of "standards" and some programming constructs. The table model stems from HTML, the access to the XML data is very similar to XPath (2.0), the node walking has a few similarities with XSL, we optionally use CSS for some elements (more will follow) and we have variables/loops and if-then-else conditionals. <br>> <br>> I have lots of ideas on how to improve the current limitations in my implementation, but the lack of time prohibits the complete implementation of all features above. For example the XPath support is limited to a few functions and a few operators yet, more will be included if I have time (and money) for that.<br>> <br>> Even with the limitations, my software is used in production for various clients, so I can promise that it is very usable, even with the mentioned unperfectness.<br>> <br>> I would like to hear any opinions on that matter. I'll be off to xmlprague friday-monday, and because of the big holes in the documentation it might be early to start this discussion now. But anyway, I just feel it's time for this email.<br>> <br>> Some background: I've implemented this in Lua and the backend is LuaTeX, a modern variant of TeX, the typsetting system. My software uses a special mode of LuaTeX in which I can write the PDF directly without generating any TeX code, but still take full advantage of the things TeX offers: great line breaking algorithm, font and image reading and other layout helpers (glue, boxes, ...)<br>> <br>> Now some links:<br>> <br>> The project page: http://speedata.github.com/publisher/<br>> Manual: http://speedata.github.com/publisher/manual/index.html<br>> Github page: https://github.com/speedata/publisher<br>> Installation instructions: https://github.com/speedata/publisher/wiki<br>> Sample layout file: http://speedata.github.com/publisher/manual/examples/en/planets/planets-layout.xml<br>> The 'data file' for the layout above: http://speedata.github..com/publisher/manual/examples/en/planets/planets-data.xml<br>> <br>> <br>> Patrick<br>> <br>> <br>> speedata UG (haftungsbeschränkt)<br>> -------------------------------------<br>> Telefon 030/57705055 <br>> Mobil 0178/1967142<br>> Mail gundlach@speedata.de<br>> Web www.speedata.de<br>> <br>> Eisenacher Straße 101<br>> 10781 Berlin<br>> -------------------------------------<br>> Amtsgericht Charlottenburg HRB 135360 B<br>> Geschäftsführer: Patrick Gundlach<br>> USt-IdNr: DE278023065<br>> <br>> <br>></blockquote></body></html>--=_49b135713df8e62f1aa6c128ñ57a000-99ab-533d-9ebd-9c1dfb9abc45_=--
Received on Friday, 8 February 2013 13:20:03 UTC