You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Luca Furini <lf...@cs.unibo.it> on 2005/09/02 09:35:41 UTC
Re: [Xmlgraphics-fop Wiki] Update of "ExtensionPoints" by JeremiasMaerki
Speaking of extensions, I'd like to resurrect the layout extensions that
were part of the code used to start the Knuth branch, but I want to be
sure I'm allowed to do it.
The set of extensions (a couple of new properties, and some new value for
an existing one) is aimed to give the user more control about the page
breaking: in particular, via these extensions it is possible to give the
application a list of properties that can be adjusted in order to fill all
the available bpd of a region (in addition / substitution to the spaces
between blocks [1]).
I started writing a wiki page about these extensions on the wiki at
http://wiki.apache.org/xmlgraphics-fop/LayoutExtensions (I really should
take some time to finish it!).
My highest-priority, short-term task is still to fix the behaviour of
page-number and page-number-citation, as I think these formatting object
must work in the next release: I have almost done, just have to finish
handling the case of justified ext. After that, obviously if there are no
objections against this, I'd like to spend some time on the extensions,
that I'm sure could come in handy for fop-users producing book-style (or
report-style) documents.
For example, here is a link to a message in the xsl-editors mailing list
requesting a feature which is completely equivalent to one of the layout
extensions:
http://lists.w3.org/Archives/Public/xsl-editors/2005JulSep/0007.html (many
thanks to Jeremias for pointing it out to me!). Should I be allowed to
keep working on this subject, I could answer him that fop will soon be
able to cope with his request.
Regards
Luca
[1] ... which makes me think that I should work on space resolution rules
too ... my to-do list keeps growing longer and longer! :-(
Re: [Xmlgraphics-fop Wiki] Update of "ExtensionPoints" by JeremiasMaerki
Posted by Jeremias Maerki <de...@greenmail.ch>.
+1 from me, especially since you'll document it properly and because it
has the nice side-effect that we get to see more of your great work!
On 02.09.2005 09:35:41 Luca Furini wrote:
> Speaking of extensions, I'd like to resurrect the layout extensions that
> were part of the code used to start the Knuth branch, but I want to be
> sure I'm allowed to do it.
>
> The set of extensions (a couple of new properties, and some new value for
> an existing one) is aimed to give the user more control about the page
> breaking: in particular, via these extensions it is possible to give the
> application a list of properties that can be adjusted in order to fill all
> the available bpd of a region (in addition / substitution to the spaces
> between blocks [1]).
>
> I started writing a wiki page about these extensions on the wiki at
> http://wiki.apache.org/xmlgraphics-fop/LayoutExtensions (I really should
> take some time to finish it!).
>
> My highest-priority, short-term task is still to fix the behaviour of
> page-number and page-number-citation, as I think these formatting object
> must work in the next release: I have almost done, just have to finish
> handling the case of justified ext. After that, obviously if there are no
> objections against this, I'd like to spend some time on the extensions,
> that I'm sure could come in handy for fop-users producing book-style (or
> report-style) documents.
>
> For example, here is a link to a message in the xsl-editors mailing list
> requesting a feature which is completely equivalent to one of the layout
> extensions:
> http://lists.w3.org/Archives/Public/xsl-editors/2005JulSep/0007.html (many
> thanks to Jeremias for pointing it out to me!). Should I be allowed to
> keep working on this subject, I could answer him that fop will soon be
> able to cope with his request.
>
> Regards
> Luca
>
> [1] ... which makes me think that I should work on space resolution rules
> too ... my to-do list keeps growing longer and longer! :-(
You should see my TODO list! :-)
Jeremias Maerki
Re: [Xmlgraphics-fop Wiki] Update of "ExtensionPoints" by JeremiasMaerki
Posted by Vincent Hennebert <vi...@enseeiht.fr>.
Luca,
I'm speaking here as a (future) Fop user. Just to let you know that I'm
definitely wanting to support you in this area. I think your extensions would
make Fop an extremely powerful typesetting system, that would eventually beat
TeX in the quality of page makup. It's all the more interesting for me since my
use of Fop would be to produce book-style documents.
Just a comment about your Wiki page: I'm not sure that modifying margins would
produce visually appealing results. May it not disturb the reader when she
notices that margins aren't the same after turning a page?
Otherwise I agree with all of your other propositions.
I wish you good success,
Vincent
Luca Furini a écrit :
> Speaking of extensions, I'd like to resurrect the layout extensions that
> were part of the code used to start the Knuth branch, but I want to be
> sure I'm allowed to do it.
>
> The set of extensions (a couple of new properties, and some new value
> for an existing one) is aimed to give the user more control about the
> page breaking: in particular, via these extensions it is possible to
> give the application a list of properties that can be adjusted in order
> to fill all the available bpd of a region (in addition / substitution to
> the spaces between blocks [1]).
>
> I started writing a wiki page about these extensions on the wiki at
> http://wiki.apache.org/xmlgraphics-fop/LayoutExtensions (I really should
> take some time to finish it!).
>
> My highest-priority, short-term task is still to fix the behaviour of
> page-number and page-number-citation, as I think these formatting object
> must work in the next release: I have almost done, just have to finish
> handling the case of justified ext. After that, obviously if there are
> no objections against this, I'd like to spend some time on the
> extensions, that I'm sure could come in handy for fop-users producing
> book-style (or report-style) documents.
>
> For example, here is a link to a message in the xsl-editors mailing list
> requesting a feature which is completely equivalent to one of the layout
> extensions:
> http://lists.w3.org/Archives/Public/xsl-editors/2005JulSep/0007.html
> (many thanks to Jeremias for pointing it out to me!). Should I be
> allowed to keep working on this subject, I could answer him that fop
> will soon be able to cope with his request.
>
> Regards
> Luca
>
> [1] ... which makes me think that I should work on space resolution
> rules too ... my to-do list keeps growing longer and longer! :-(
>
>
Re: [Xmlgraphics-fop Wiki] Update of "ExtensionPoints" by JeremiasMaerki
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 02.09.2005 10:24:12 Finn Bock wrote:
> [Luca]
>
> > Speaking of extensions, I'd like to resurrect the layout extensions
>
> That isn't exactly use of the term "extension" which I'm using and which
> I think Jeremias is using in the ExtensionPoints wiki. Your extensions
> are additional useful features, when I talk about extensions it is the
> ability to dynamicly load additional behaviour without modifying FOP
> sources.
Well, extension is such a generic term, like plug-in (<ot>and yet the
concept was patentable</ot>). Anyway, I don't think that Luca's
extensions differ so much from the extensions I documented in the Wiki.
> If your features could be implemeted as dynamicly loaded code, the
> result would be a lean FOP with incredible power ...
No quite related to this thread, but just to let you know: I'm currently
working on the generic extension mechanism that, for example, renderers
will be able to use. I realized it would probably not be much more work
to implement it generically than to hard-code the PostScript extensions
into FOP.
> > that
> > were part of the code used to start the Knuth branch, but I want to be
> > sure I'm allowed to do it.
>
> .. and you wouldn't have to ask. :-)
>
> OTOH, I'm not entirely sure how to design and implement such a system
> that dynamicly loads code into the layout system.
Neither am I in this case. At the very least it would involve
subclassing certain LMs and dynamically registering them for the layout
engine. But that would probably be the least of problems, since the
new behaviour goes right into the breaking algorithm.
> > The set of extensions (a couple of new properties, and some new value
> > for an existing one)
>
> New properties are fine, new values to existing properties are bad, I
> think. It basicly makes the fo file into a FOP file, since no other
> processer can handle the 'illegal' values. It would be better to define
> fox:display-align="fill" which when specified will override the value of
> display-align.
Good point.
<snip/>
Jeremias Maerki
Re: [Xmlgraphics-fop Wiki] Update of "ExtensionPoints" by JeremiasMaerki
Posted by Finn Bock <bc...@worldonline.dk>.
[Luca]
> Speaking of extensions, I'd like to resurrect the layout extensions
That isn't exactly use of the term "extension" which I'm using and which
I think Jeremias is using in the ExtensionPoints wiki. Your extensions
are additional useful features, when I talk about extensions it is the
ability to dynamicly load additional behaviour without modifying FOP
sources.
If your features could be implemeted as dynamicly loaded code, the
result would be a lean FOP with incredible power ...
> that
> were part of the code used to start the Knuth branch, but I want to be
> sure I'm allowed to do it.
.. and you wouldn't have to ask. :-)
OTOH, I'm not entirely sure how to design and implement such a system
that dynamicly loads code into the layout system.
> The set of extensions (a couple of new properties, and some new value
> for an existing one)
New properties are fine, new values to existing properties are bad, I
think. It basicly makes the fo file into a FOP file, since no other
processer can handle the 'illegal' values. It would be better to define
fox:display-align="fill" which when specified will override the value of
display-align.
> is aimed to give the user more control about the
> page breaking: in particular, via these extensions it is possible to
> give the application a list of properties that can be adjusted in order
> to fill all the available bpd of a region (in addition / substitution to
> the spaces between blocks [1]).
I wonder why you don't mention that line-height is a min/opt/max space.
Surely that will (when implemented) be usefull way to limit the size og
empty areas.
regards,
finn