Re: Hyphenation
Manuel Mall wrote: Not sure what other committers and the PMC think but as a vote on the release has started I would suggest no further changes to the codebase unless agreed? What I am saying is - by all means do the development but don't put it back into svn until after the release. Ok, this seems a good idea. Regards Luca
Re: fo:marker and white space
Jeremias Maerki wrote: Sounds like a good plan to me. Would you go after that? Jeremias: I have similar concerns to Manuel about this. Moving the handleWhitespace method to a different class is probably okay, but I don't think we should start making any major changes to Whitespace handling until we have the design nailed down. It is still unclear exactly what the spec intends in some places. Manuel has written a Wiki which attempts to document the intention of the spec and presents some ideas on how to implement this functionality. http://wiki.apache.org/xmlgraphics-fop/LineLayout/WhitespaceHandling On 15.11.2005 18:06:13 Andreas L Delmelle wrote: In this respect: I still wonder whether it wouldn't be more convenient to split up the whitespace handling, and deal with the inlines separately. Currently, InlineCharIterator needs to generate boundary characters to indicate start- or end-inline. If we would deal with the whitespace of the inlines at inline-level itself, it should become far more straightforward to apply the 'special' rules (no removal of the first/last space of the inline, or before it). On top of that, it does away with the need to chain together all FOText instances of a whole block (thus making that ugly static 'lastFOTextProcessed' obsolete?) Chris
Re: fo:marker and white space
Well, my fault. I didn't so much follow the whole whitespace discussion to know every detail. I assumed there was some kind of consensus by now. On 16.11.2005 11:15:48 Chris Bowditch wrote: Jeremias Maerki wrote: Sounds like a good plan to me. Would you go after that? Jeremias: I have similar concerns to Manuel about this. Moving the handleWhitespace method to a different class is probably okay, but I don't think we should start making any major changes to Whitespace handling until we have the design nailed down. It is still unclear exactly what the spec intends in some places. Manuel has written a Wiki which attempts to document the intention of the spec and presents some ideas on how to implement this functionality. http://wiki.apache.org/xmlgraphics-fop/LineLayout/WhitespaceHandling On 15.11.2005 18:06:13 Andreas L Delmelle wrote: In this respect: I still wonder whether it wouldn't be more convenient to split up the whitespace handling, and deal with the inlines separately. Currently, InlineCharIterator needs to generate boundary characters to indicate start- or end-inline. If we would deal with the whitespace of the inlines at inline-level itself, it should become far more straightforward to apply the 'special' rules (no removal of the first/last space of the inline, or before it). On top of that, it does away with the need to chain together all FOText instances of a whole block (thus making that ugly static 'lastFOTextProcessed' obsolete?) Chris Jeremias Maerki
Illegal property values
While working on the implementation of hyphenation-ladder-count, I noticed
that at the moment the property system can return illegal values
coming from the fo file instead of the fallback value defined by the
specs.
There are significant differences in wording between XSL 1.0 and 1.1: for
example, concerning hyphenation-ladder-count 1.0 has (7.15.2):
integer an integer greater than or equal to 1
While 1.1 (7.16.2) reads:
number an integer greater than or equal to 1. If a zero, negative, or
non-integer value is provided, the value will be rounded to the nearest
integer value greater than or equal to 1
So, should the property be improperly set to -0.5:
- if we want to follow closely 1.0, we should stop with an error
- if we follow 1.1 we should continue using 1 instead, maybe with a
warning message
There are other properties with a validity range and a fallback value:
column-count, initial-page-number, column-number, number-columns-repeated,
number-columns-spanned, number-rows-spanned, hyphenation-{push,
remain}-character-count; only hyphenation-ladder-count does not have a
fallback value in 1.0, so maybe this was just an oversight.
Note that the fallback value is different, in general, from the default
value, as it is derived from the illegal value by rounding.
At the moment the layout process continues with the incorrect values, and
this could create errors in several different places; for example a
non-integer value would probably create an error if we assign it to an
integer variable, a negative integer value could create an
IllegalArgumentException if we use it as the size of an array (this
happens, for example, with a negative column-count) ...
Regards
Luca
Re: Illegal property values
On Nov 16, 2005, at 11:51, Luca Furini wrote:
snip /
There are other properties with a validity range and a fallback
value: column-count, initial-page-number, column-number, number-
columns-repeated, number-columns-spanned, number-rows-spanned,
hyphenation-{push, remain}-character-count; only hyphenation-ladder-
count does not have a fallback value in 1.0, so maybe this was just
an oversight.
Note that the fallback value is different, in general, from the
default value, as it is derived from the illegal value by rounding.
I guess we'll have to have a look at all these properties to see how
the fallbacks are dealt with.
I remember that, when I implemented the default value for the column-
number property (+/- 2 months ago), the described fallback value in
case of zero-or-negative values wasn't provided, but the error (=
no error according to the Rec) was dealt with in the TableCell or
TableColumn's bind() method. I coded this functionality into
ColumnNumberPropertyMaker.get() [Didn't get around to rounding the
value in case it's non-integer, since I wasn't sure how to check for
that... there's still a TODO for that]
Anyway, it was quite straightforward to implement that logic into the
Property system.
I'm thinking that, if this is shared by a number of properties, then
the option should be investigated to abstract this out into a common
Maker for the props in question.
I'll look into this as soon as I find some spare time.
Cheers,
Andreas
Re: fo:marker and white space
On Wed, Nov 16, 2005 at 08:15:47AM +0800, Manuel Mall wrote: I have no problems with the suggestion to move the white space handling from Block into its own class so other fo's that need it can make use of it. However, I still need to be convinced that pushing it down to inline level is actually of benefit. I am afraid we will end up with the same problem we now have at LM level, that is text for a paragraph needs to be analysed across fo boundaries and the current LM structures are very much in the way of doing that. Whitespace needs to be handled across fo boundaries as well. The current iterator structure was designed to exactly facilitate that. It seems to be doing it well and I see no reason to replace it. linefeed-treatment is a local operation on a single character. white-space-collapse does not cross FO boundaries because the spec limits this to sibling character FOs. Only white-space-treatment extends beyond FO boundaries, but its treatment in handleWhitespace is only the first stage. At line building it needs to be revisited. That means that theoretically handleWhitespace can be done within each FO. But practically it may be better to wait until we have settled ideas about this stage, scanning for linebreak opportunities and gathering of Knuth elements. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: [VOTE] Release FOP Trunk as FOP 0.90alpha1
+1 Simon On Tue, Nov 15, 2005 at 09:14:12PM +0100, Jeremias Maerki wrote: This is it. Just to make it clear again: This is a a release vote and therefore a PMC vote, but every FOP committer is invited to place his vote or raise any objections. Noone gets ignored. Although fop-dev is in the CC, please place your votes on [EMAIL PROTECTED] Even though I haven't fully finished all of the documentation, yet, I'd like to start the vote. I'll have everthing finished by tomorrow evening (CET). I don't intend to do any more code changes, only the last documentation updates. http://wiki.apache.org/xmlgraphics-fop/ReleasePlanFirstPR shows the release plan and the status of the proceedings. I know of no legal problems needing attention. The external dependencies are well documented and every JAR in the lib directory is accompanied by its license. Hyphenation files have been removed. The unknown origin of some long-existing example FO files is not a problem IMO. 0.90alpha1 will carry a big warning sign in the README file that the software is a preview release and should not be used in production unless thoroughly tested for the target environment. It is intended to let everybody know that FOP is back in business and to produce feedback on our new piece of software from users that don't (or can't) download the code from SVN. I'd like to propose to release FOP SVN Trunk as version 0.90alpha1. +1 from me, obviously. Jeremias Maerki - Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Simon Pepping home page: http://www.leverkruid.nl
