Re: FOP website, release preparations: refactoring necessary

I have figured out how the documentation files work and how to edit them. I still have to figure out how to get the site to build on my local machine and then I will be in business. What way you suggest I send the changes to you ? Thanks, Patrick Paul Jeremias Maerki wrote: Very cool! Than

Re: FOP website, release preparations: refactoring necessary

Ok, so from what I understand you want to do, I think that what the Lenya project did looks good. http://lenya.apache.org/ What do you think ? Patrick Paul Jeremias Maerki wrote: While we're at it: In preparation for the first release we need to start thinking about a refactoring of our web

DO NOT REPLY [Bug 36391] - [PATCH] reference-orientation and negative values

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36391] - [PATCH] reference-orientation and negative values

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36391] - [PATCH] reference-orientation and negative values

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36391] - [PATCH] reference-orientation and negative values

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36391] New: - [PATCH] reference-orientation and negative values

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: Collapsing borders: FOTree stage -- progress update

On Aug 26, 2005, at 21:32, Jeremias Maerki wrote: You got me a little shocked when I read your post. Really? Good! Nothing personal, but I always tend to take 'shock-and-awe' to be a sign that I'm on the right track. I remember having driven Glen crazy on a few occasions, and that was precis

DO NOT REPLY [Bug 35918] - [PATCH] Shapes are slightly shifted with respect to lines on larger graphics

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: page-number and page-number-citation problem

Luca Furini wrote: Yes, undoubtedly a two-pass rendering would produce a better output: and after all, even LaTex needs to be run twice if there are page number citations. Backtracking with some attempts to minimize the scope for re-layout should be enough, though somewhat less straightforward

Re: page-number and page-number-citation problem

Luca Furini wrote: PageNumberLM.get() calls getCurrentPV().getPageNumberString(), but, as pagination is performed later, it always get the page-sequence initial page number In the maintenance branch, the formatted page number string was produced just as a new page was set up. I wonder whether

Re: Collapsing borders: FOTree stage -- progress update

You got me a little shocked when I read your post. Now I'm afraid I should have realized earlier on what you're up to. I hope you were able to reuse at least a bit of the code I already wrote for the collapsing border model. As far as I can remember most of that already worked quite well (everythin

Collapsing borders: FOTree stage -- progress update

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, First of all: many, many thanks to Finn for taking care of the default border-precedence values! Secondly: sorry for the rather long post. This message is solely intended to keep you guys (and other interested parties) informed about my p

Re: Relative font weights and font selection

On Fri, 26 Aug 2005 10:35 pm, Vincent Hennebert wrote: > Victor Mote a écrit : > > I am ignoring font-stretch for now. I am unclear whether it works > > similarly to font-weight, or whether it is totally resolvable in > > the FO Tree. Interestingly, CSS 2.1 (the only version of CSS 2 > > still avai

FOP Visuals

For those who don't want to run BatchDiffer themselves, I've uploaded a ZIP full of PNGs, one per layout engine test case combined from output from the PDF, PS and Java2D renderers. http://people.apache.org/~jeremias/fop/fop-visuals-2005-08-26.zip (4.6MB) Just in case you're curious. :-) Jeremia

Re: Relative font weights and font selection

Victor Mote a écrit : I am ignoring font-stretch for now. I am unclear whether it works similarly to font-weight, or whether it is totally resolvable in the FO Tree. Interestingly, CSS 2.1 (the only version of CSS 2 still available at W3C) removes font-stretch entirely!!??!! As I understand the

Re: Relative font weights and font selection

On 26.08.2005 15:00:46 Victor Mote wrote: > Jeremias Maerki wrote: > > > I believe that font-stretch has to included just like > > font-weight to select the actual font. > > Sorry to be unclear. I understand that font-stretch must be included. The > issue is whether the "wider" and "narrower" c

Re: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system

Yeah: Wow! Finn, you're the specialist here. Can you take the lead on this one? On 26.08.2005 15:15:27 bugzilla wrote: > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT > . > AN

Re: page-number and page-number-citation problem

Luca Furini wrote: The computation, in itself, is easy, as the LineLM already has all the necessary information: line width, unadjusted width, available stretch and shrink. I think shrinking/stretching the spaces in the case where the guessed space doesnt match the actual is an improvement

FOP extension to output custom PostScript instructions

As you know I'm currently updating the PostScript renderer. I'd like to create a few FOP extensions for outputting custom PostScript code at key places so people doing mass-printing can insert media selection code and stuff like that into the PostScript stream. fo:declaration is to be extended to:

DO NOT REPLY [Bug 36379] - [PATCH] Revised percentage resolution system

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36379] - [PATCH] Revised percentage resolution system

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36379] - [PATCH] Revised percentage resolution system

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36379] - [PATCH] Revised percentage resolution system

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

RE: Relative font weights and font selection

Jeremias Maerki wrote: > I believe that font-stretch has to included just like > font-weight to select the actual font. Sorry to be unclear. I understand that font-stretch must be included. The issue is whether the "wider" and "narrower" constraints can be processed in the FOTree by simply bumpi

Re: page-number and page-number-citation problem

Jeremias Maerki wrote: The computation, in itself, is easy, as the LineLM already has all the necessary information: line width, unadjusted width, available stretch and shrink. It only easy if you have enough stretch and shrink available, right? Well, we can always *pretend* it is enough! :

RE: percentages on i-p-d/b-p-d/height

Manuel Mall wrote: > Any one with better ideas / comments? FOray solved (I think) this problem by a combination of 1) deferring the resolution of any values that are dependent on area tree values until those values are available, and 2) leaving the logic for such resolution in the FOTree (so it

DO NOT REPLY [Bug 36356] - Problem with column balancing in multi-column layout

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: page-number and page-number-citation problem

Ah, yes, and the fourth possibility would be to simply create a transformation matrix in the renderer to squeeze the value in without having to adjust the area tree. Just joking... :-) On 26.08.2005 14:03:59 Jeremias Maerki wrote: > > What do you think? Do someone see a different strategy? Jeremi

Re: page-number and page-number-citation problem

A question where I'm more at home than with the FO tree... :-) On 26.08.2005 13:22:58 Luca Furini wrote: > There is a layout problem with fo:page-number and fo:page-number-citation, > already pointed out but still unresolved. > > I think, these formatting objects are very similar, even if their

page-number and page-number-citation problem

There is a layout problem with fo:page-number and fo:page-number-citation, already pointed out but still unresolved. I think, these formatting objects are very similar, even if their actual handling is quite different: they both must be replaced by an information (a page number) that is (or co

Re: percentages on i-p-d/b-p-d/height

I'm sorry, I'd better shut up if I can't dive fully into this matter. I'm just wasting your and my time. Finn seems to have a better grip on this area. On 26.08.2005 11:21:58 Manuel Mall wrote: > On Fri, 26 Aug 2005 05:14 pm, Jeremias Maerki wrote: > > On 26.08.2005 10:41:31 Manuel Mall wrote: > >

Re: FOTree Table FOs -- definitely non-urgent, just probing...

Jeremias Maerki wrote: As all of the table FOs are direct descendants of FObj this is a reasonable thought. Might really be worthwhile. Yes I second that - go for it Andreas! Chris

Re: percentages on i-p-d/b-p-d/height

Finn Bock wrote: It sounds just like a job for the property system since it already deals with the corresponding properties and knows if a property is explicitly set. I don't think that there is an existing way to check if a fo is block-level but that can be added (like generatesReferenceAre

Re: percentages on i-p-d/b-p-d/height

On Fri, 26 Aug 2005 06:00 pm, Finn Bock wrote: > [Manuel Mall] > > > The spec says: The percentage is calculated with respect to the > > corresponding dimension of the closest area ancestor that was > > generated by a block-level formatting object. If that dimension is > > not specified explicitly

Re: percentages on i-p-d/b-p-d/height

[Manuel Mall] The spec says: The percentage is calculated with respect to the corresponding dimension of the closest area ancestor that was generated by a block-level formatting object. If that dimension is not specified explicitly (i.e., it depends on content's block/inline-progression-dimensio

Re: percentages on i-p-d/b-p-d/height

On Fri, 26 Aug 2005 05:14 pm, Jeremias Maerki wrote: > On 26.08.2005 10:41:31 Manuel Mall wrote: > > The spec says: The percentage is calculated with respect to the > > corresponding dimension of the closest area ancestor that was > > generated by a block-level formatting object. If that dimension

Re: percentages on i-p-d/b-p-d/height

On 26.08.2005 10:41:31 Manuel Mall wrote: > The spec says: The percentage is calculated with respect to the > corresponding dimension of the closest area ancestor that was generated > by a block-level formatting object. If that dimension is not specified > explicitly (i.e., it depends on content's

Re: Relative font weights and font selection

On 25.08.2005 18:10:51 Victor Mote wrote: > Victor Mote wrote (August 8): > > > Manuel Mall wrote: > > > > > Regarding the "bolder", "lighter" issue and the general > > font selection > > > I looked at the "pre-patch for FOrayFont adaptation to Fop" > > > (http://issues.apache.org/bugzilla/sho

percentages on i-p-d/b-p-d/height

The spec says: The percentage is calculated with respect to the corresponding dimension of the closest area ancestor that was generated by a block-level formatting object. If that dimension is not specified explicitly (i.e., it depends on content's block/inline-progression-dimension), the value is

Re: JAXG snapshot available (was: Re: API discussion (revived))

On 25.08.2005 22:17:33 Simon Pepping wrote: > Jeremias, > > It is a good package. I have a few remarks. Thanks a lot for taking time to review! > 1. At some point I wanted it to be possible to set input and output >types on the Factory. In that way it would be possible to write a >facto

Re: Non-implemented props: border-*-precedence

Finn Bock wrote: [Andreas L Delmelle] Any hint appreciated. I have added support for the default values in a TableBorderPrecedence property maker class. Since I have added a new file to SVN must I do something to make line ending right? Yes you need to set the SVN property svn:eol-sty

Re: Non-implemented props: border-*-precedence

On 26.08.2005 09:09:45 Finn Bock wrote: > [Andreas L Delmelle] > > > Any hint appreciated. > > I have added support for the default values in a TableBorderPrecedence > property maker class. Cool. It's so good to see names other than mine on the commits list. > Since I have added a new file to

Re: FOTree Table FOs -- definitely non-urgent, just probing...

As all of the table FOs are direct descendants of FObj this is a reasonable thought. Might really be worthwhile. On 25.08.2005 21:45:16 Andreas L Delmelle wrote: > Hi all, > > Has anyone ever thought about introducing an abstract class for > table-related FOs, say TableFObj, that would be extend

Re: Non-implemented props: border-*-precedence

[Andreas L Delmelle] Any hint appreciated. I have added support for the default values in a TableBorderPrecedence property maker class. Since I have added a new file to SVN must I do something to make line ending right? Is there a way in our test system to check the values of properties