getPageCount and FOP 1.0dev

2005-07-27 Thread Manuel Mall
, 27 July 2005 14:08 To: fop-users@xmlgraphics.apache.org Subject: Re: getPageCount and FOP 1.0dev No, but you're welcome to help improve the situation. :-) On 27.07.2005 03:50:46 Manuel Mall wrote: Jeremias post on fop-dev suggesting to push for a release made me curious to check out if the new

Re: getPageCount and FOP 1.0dev

2005-07-27 Thread Manuel Mall
Jeremias, Excellent, thanks for the pointers. I'll have a go at it over the coming weekend as I am going away for a few days now. Manuel On Wed, 27 Jul 2005 02:43 pm, Jeremias Maerki wrote: Manuel, thanks for grabbing this. I think the easiest thing will be to recreate what was in 0.20.5.

Re: getPageCount and FOP 1.0dev

2005-07-30 Thread Manuel Mall
I think I have a handle on how to obtain the number of pages generated per page sequence. However, I am struggling with how to best access the FormattingResults structure in Fop.java. In 0.20.5 the structure lived in StreamRenderer which is now sort of AreaTreeHandler. It is not clear to me how

RE: getPageCount and FOP 1.0dev

2005-07-30 Thread Manuel Mall
As this is now done anything else I can help with (keep it small to start with please)? Manuel

Re: getPageCount and FOP 1.0dev

2005-07-30 Thread Manuel Mall
Managed to install Forrest 0.7 and installed and built the xmlgraphics site from http://svn.apache.org/repos/asf/xmlgraphics/site/. However, I am a bit confused about how this hangs together as there are two sites related to fop: xmlgraphics.apache.org and xml.apache.org/fop. So I can build

FOP Compliance Page was: getPageCount and FOP 1.0dev

2005-07-31 Thread Manuel Mall
it work intensive to maintain. Feedback please Manuel On Sun, 31 Jul 2005 12:51 am, Jeremias Maerki wrote: ... On 30.07.2005 18:38:55 Manuel Mall wrote: ... On Sat, 30 Jul 2005 10:11 pm, Jeremias Maerki wrote: ... ... The file that would need to be changed is this one: http

Re: FOP Compliance Page was: getPageCount and FOP 1.0dev

2005-07-31 Thread Manuel Mall
On Mon, 1 Aug 2005 09:09 am, The Web Maestro wrote: On Jul 31, 2005, at 4:28 PM, Manuel Mall wrote: ... I seems originally the compliance page was created using some XSLT transformations (see src/documentation/resources/stylesheets). Has this approach been abandoned? I can't find the input

Re: DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class

2005-08-01 Thread Manuel Mall
://marc.theaimsgroup.com/?l=fop-devm=108947697611032w=2 On Mon, 1 Aug 2005 02:20 am, Andreas L Delmelle wrote: On Jul 30, 2005, at 17:34, Manuel Mall wrote (on bugzilla): Manuel, Devs, To be able to simply replace a 0.20.5 fop.jar with 1.0dev fop.jar I have written a backwards compatible

Re: DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class

2005-08-01 Thread Manuel Mall
On Tue, 2 Aug 2005 12:31 am, Andreas L Delmelle wrote: On Aug 1, 2005, at 11:37, Manuel Mall wrote: no argument from me against what you are proposing and also Joerg in [1]. We can still have a Driver.java for backwards compatibility for those who want to plug and play either

Re: FOP Compliance Page was: getPageCount and FOP 1.0dev

2005-08-01 Thread Manuel Mall
Gentlemen, can we agree on the following? 1. The compliance page must be able to handle multiple FOP versions. 2. Which versions are shown at any point in time and how they are called will be decided on a case by case basis. Currently we are talking only about the last official release

Re: FOP Compliance Page was: getPageCount and FOP 1.0dev

2005-08-01 Thread Manuel Mall
Victor, thanks for the background information. On Tue, 2 Aug 2005 09:19 am, Victor Mote wrote: Manuel Mall wrote: BTW, why do we have the 3 columns Basic | Extended | Complete? Every row will only have one cell out of those 3 filled out. Wouldn't it make more sense to have a single column

Re: FOP Compliance Page was: getPageCount and FOP 1.0dev

2005-08-03 Thread Manuel Mall
On Tue, 2 Aug 2005 04:52 pm, Jeremias Maerki wrote: On 02.08.2005 03:18:44 Manuel Mall wrote: ... ii) Change the layout to a single column per version and indicate in a single separate column at which conformance level a particular FO object or property lives (For a sample see the XSL-FO

Re: Att: Manuel

2005-08-04 Thread Manuel Mall
Jeremias, On Thu, 4 Aug 2005 04:44 pm, Jeremias Maerki wrote: Manuel, given your enthusiasm for helping us (THANK YOU!) and the number of recent contributions, may I ask you to sign an Individual Contributor License Agreement (ICLA) and send that to the ASF? ... Just faxed it off. Had to

Checks for testcase was: (Re: DO NOT REPLY [Bug 36025] - [PATCH] font-size testcases)

2005-08-04 Thread Manuel Mall
Chris, On Thu, 4 Aug 2005 09:31 pm, [EMAIL PROTECTED] wrote: ... --- Additional Comments From [EMAIL PROTECTED] ... I have added some checks to make the tests a little more effective at detecting regressions. I would be grateful if you could have a go at this yourself next time. If

Re: Checks for testcase was: (Re: DO NOT REPLY [Bug 36025] - [PATCH] font-size testcases)

2005-08-04 Thread Manuel Mall
Chris, On Thu, 4 Aug 2005 10:59 pm, Chris Bowditch wrote: Manuel Mall wrote: Chris, Hi Manuel, ... The checks are actually against the Area Tree Output. You can generate it and see what it looks like for any fo by running the following command line: fop foo.fo -at foo.xml OK, got

Re: Checks for testcase was: (Re: DO NOT REPLY [Bug 36025] - [PATCH] font-size testcases)

2005-08-04 Thread Manuel Mall
On Thu, 4 Aug 2005 11:17 pm, Jeremias Maerki wrote: I've documented some of the stuff concerning layoutengine tests on the Wiki: http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests I see that it was not enough, so I'll add some more info later today. Gotta run now. Sorry.

font-weight in area tree

2005-08-05 Thread Manuel Mall
I am trying to write a testcase for the font-weight property and noticed that the font-weight property is not shown in the area tree, i.e. something like: fo:block font-weight=boldfont-weight=bold/fo:block produces an area tree output like: block bap=0 0 0 0 bpd=14400 bpda=14400 ipd=595275

Relative font-sizes

2005-08-06 Thread Manuel Mall
Hi fop-devs, I am current looking into getting relative font-size property values, e.g. larger or smaller, implemented. The spec gives some leeway in that area, i.e. it says in 7.8.4: If the parent element's size is not close to a table entry, the user agent is free to interpolate between

Relative font weights and font selection

2005-08-06 Thread Manuel Mall
I was looking at how to implement support for relative font weights (bolder and lighter). The spec says that a relative font weight refers to the next lighter or bolder font. This means we cannot simply subtract/add 100 to the weight but we have to find the next font relative to the current

Re: ant junit target fails

2005-08-07 Thread Manuel Mall
On Sat, 6 Aug 2005 10:37 pm, you wrote: I am consistently getting the error below on the ant junit target. snip/ Further investigation showed that I can get rid of the error by upgrading the xerces/xalan combination. Here is a summary of what I found: xalan 2.4.1/xerces 2.2.1 as extracted from

Re: ant junit target fails

2005-08-07 Thread Manuel Mall
On Mon, 8 Aug 2005 02:41 am, Simon Pepping wrote: snip/ IMHO An upgrade of the jars in FOP does not solve the problem of this test file. Simon, 1. do you actually understand what the problem is because I don't? The test file (test/xml/bugtests/block.fo) is trivial. It works from the fop

Re: Relative font weights and font selection

2005-08-07 Thread Manuel Mall
and be isolated enough for you not to get lost in FOP's complexity. Still, it's not a minor bit to chew. Anyway, it's up to you. On 06.08.2005 17:44:02 Manuel Mall wrote: I was looking at how to implement support for relative font weights (bolder and lighter). The spec says that a relative

URI Resolution (was: Relative font weights and font selection)

2005-08-07 Thread Manuel Mall
On Mon, 8 Aug 2005 01:04 am, Jeremias Maerki wrote: snip/ Another important area would be URI resolution and proper and consistent resolution of relative paths. I think that is something that bugs especially our users through Cocoon. There are a few (older) notes about that in the Wiki. In

external-graphics supported formats

2005-08-09 Thread Manuel Mall
Hi, I just converted the bgimg300dpi.jpg image using Photoshop into PNG, BMP, EPS, TIF and GIF formats and tried to include those as e-g. PNG and TIF seem to be working although they are shown at a different size than the original JPEG. EPS shows blank. BMP and GIF cause exceptions. Is this

Re: external-graphics supported formats

2005-08-09 Thread Manuel Mall
On Tue, 9 Aug 2005 06:21 pm, Jeremias Maerki wrote: On 09.08.2005 11:55:55 Manuel Mall wrote: snip / PNG and TIF seem to be working although they are shown at a different size than the original JPEG. Please check that the DPI/resolution settings in the different versions of the file

Re: external-graphics supported formats

2005-08-09 Thread Manuel Mall
On Tue, 9 Aug 2005 08:15 pm, Jeremias Maerki wrote: On 09.08.2005 13:57:09 Manuel Mall wrote: On Tue, 9 Aug 2005 06:21 pm, Jeremias Maerki wrote: On 09.08.2005 11:55:55 Manuel Mall wrote: snip / BMP and GIF cause exceptions. That's not so good. I'll investigate

Line numbers in error messages

2005-08-11 Thread Manuel Mall
Jeremias, couldn't agree more - I don't think its on the WIKI unless its implied under central error message producer. BTW, what's the FOP policy on WIKI changes. Any one allowed to do it? Manuel The error produced from the Ant task is: [fop] 11/08/2005 18:46:24

Re: Batik images and resolution

2005-08-12 Thread Manuel Mall
On Fri, 12 Aug 2005 06:00 pm, Thomas DeWeese wrote: Jeremias Maerki wrote: snip/ Yes it does. It uses the 'properties' interface to expose this (and lots of other) information. The properties in question are x_pixels_per_unit, y_pixels_per_unit pixel_units. The TIFF reader exposes

Re: TODO tags

2005-08-13 Thread Manuel Mall
Actually when I run javadoc I get over 100 warnings. Many related to @TODO tags, quite a about incorrect @param and some about unresolvable @see. You want any help with fixing these? Just nominate a set of packages you want me to look at and I will go through fixing them up with respect to

Re: More about build.xml

2005-08-13 Thread Manuel Mall
One minor item to add. I have modified my local build.xml to include source=1.3 in the javac element. This means the bytecode my Java 5.0 environment generates at least runs under 1.4 and 1.3. This mainly helps me to switch between 5.0 and 1.4 without having to recompile. I wonder if this

Re: TODO tags

2005-08-14 Thread Manuel Mall
Forgot to add: Anything else you would like me to clean up? Manuel On Mon, 15 Aug 2005 10:11 am, Manuel Mall wrote: On Mon, 15 Aug 2005 03:18 am, J.Pietschmann wrote: Manuel Mall wrote: Actually when I run javadoc I get over 100 warnings. I started at 156 :-) You want any help

Re: DO NOT REPLY [Bug 36082] - [PATCH] Relative URIs are not correctly resolved

2005-08-15 Thread Manuel Mall
On Mon, 15 Aug 2005 06:43 pm, [EMAIL PROTECTED] wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=36082 --- Additional Comments From [EMAIL PROTECTED] 2005-08-15 12:43 --- Applied. Thanks a lot, Manuel. This is a big step in the right direction!

Re: DO NOT REPLY [Bug 36082] - [PATCH] Relative URIs are not correctly resolved

2005-08-15 Thread Manuel Mall
On Mon, 15 Aug 2005 08:20 pm, Jeremias Maerki wrote: On 15.08.2005 14:04:16 Manuel Mall wrote: On Mon, 15 Aug 2005 06:43 pm, [EMAIL PROTECTED] wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=36082 --- Additional Comments From [EMAIL PROTECTED] 2005-08-15 The URI

Re: Batik images and resolution

2005-08-15 Thread Manuel Mall
On Sun, 14 Aug 2005 09:14 pm, Jeremias Maerki wrote: Oh, right, looks like the CCFFilter needs to be ported from the maintenance branch to the trunk. I didn't remember that one. The Batik codecs are actually not so much involved in this case, since the TIFF doesn't have to be fully decoded.

TIFF images and color model

2005-08-17 Thread Manuel Mall
This is probably more a Batik question but as I encountered it in the FOP context and Batik people are on this list here we go: When decoding a TIFF image (black / white fax) using Batik and then looking at the returned color space, e.g. image.getColorModel().getColorSpace(); that color space

WIKI update to FOP IDE Setup Guide

2005-08-17 Thread Manuel Mall
Just did my first FOP WIKI update. I added instructions for NetBeans to http://wiki.apache.org/xmlgraphics-fop/FOPIDESetupGuide. Hope that's OK. Please yell if I shouldn't do this or should do it differently. Manuel

Percentages in XSL-FO

2005-08-18 Thread Manuel Mall
I am currently looking at the XSL-FO spec with respect to resolving percentages in property values because it was mentioned on this list that the current system in FOP needs improvements. For many properties the spec refers to the 'closest ancestor block area that is not a line area'. This again

Re: Percentages in XSL-FO

2005-08-19 Thread Manuel Mall
, Jeremias Maerki wrote: On 18.08.2005 17:32:54 Manuel Mall wrote: I am currently looking at the XSL-FO spec with respect to resolving percentages in property values because it was mentioned on this list that the current system in FOP needs improvements. For many properties the spec refers

Re: Percentages in XSL-FO

2005-08-20 Thread Manuel Mall
On Sat, 20 Aug 2005 11:33 pm, Jeremias Maerki wrote: snip/ BTW, I'm very positively surprised and extremely pleased about your contributions so far. Is your boss supporting you or have you simply become addicted to FOP? :-) Just curious. Jeremias, Thank you for your kind words. If you mean

Re: API discussion (revived)

2005-08-21 Thread Manuel Mall
On Sun, 21 Aug 2005 02:29 pm, Jeremias Maerki wrote: The API discussion thread around 2005-08-03 trailed off. I'd like to revive it again because I feel that is something that needs to be done. Anybody against moving the CLI to a org.apache.fop.cli package? For command line applications I

Re: API discussion (revived)

2005-08-21 Thread Manuel Mall
On Sun, 21 Aug 2005 04:05 pm, Jeremias Maerki wrote: On 21.08.2005 09:08:48 Manuel Mall wrote: On Sun, 21 Aug 2005 02:29 pm, Jeremias Maerki wrote: snip/ e) (my preference) Move the API to org.apache fop and the CLI to org.apache.fop.cli (including the Main class). Fine with me. I still like

Re: Percentages in XSL-FO

2005-08-24 Thread Manuel Mall
-grained enough to handle every case and still limit the additional code to where it is needed. [Manuel Mall] I have been working on this for the last couple of days and I am not so sure any more about the 'being on the right course' bit. So this is a bit of a cry for feedback. I

background-position-vertical and -horizontal

2005-08-24 Thread Manuel Mall
When setting a relative background position the positioning is relative to the size of the area the background is applied to. Currently the position calculation is done when the area is created, i.e. when the background trait is set. However, at that point in time fop may not know the bpd and

Re: background-position-vertical and -horizontal

2005-08-25 Thread Manuel Mall
adding the exception and before fixing the problems? I can help you there, if you like. On 25.08.2005 08:40:22 Manuel Mall wrote: The safety check in addBackground is already there. This is how I stumbled across it as it is triggered by one of the layout engine tests. I'll look

Re: background-position-vertical and -horizontal

2005-08-25 Thread Manuel Mall
OK thanks, another thing to look at - I am certainly not running out of work here, just the payment is lousy :-). On Thu, 25 Aug 2005 03:08 pm, Finn Bock wrote: Manuel Mall wrote: The safety check in addBackground is already there. This is how I stumbled across it as it is triggered by one

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

2005-08-26 Thread 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-dimension), the value is

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

2005-08-26 Thread Manuel Mall
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

2005-08-26 Thread Manuel Mall
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 (i.e

Re: FOP website, release preparations: refactoring necessary

2005-08-27 Thread Manuel Mall
Patrick, assuming you have forrest installed you build by simply typing forrest in the directory you checked the sources out from subversion, that is the directory where the forrest.properties file is in. The generated site is then in build/site. For delivering changes the following procedure

Re: Collapsing borders: FOTree stage -- progress update

2005-08-27 Thread Manuel Mall
On Sat, 27 Aug 2005 02:07 am, Andreas L Delmelle wrote: Hi all, snip/ * The first step I took was moving much of the logic that is currently in CollapsingBorderModelEyeCatching (in the layout package) to CommonBorderPaddingBackground. I must admit I know very little about collapsing borders.

Re: Collapsing borders: FOTree stage -- progress update

2005-08-28 Thread Manuel Mall
On Sun, 28 Aug 2005 10:33 am, Manuel Mall wrote: On Sat, 27 Aug 2005 02:07 am, Andreas L Delmelle wrote: Hi all, snip/ * The first step I took was moving much of the logic that is currently in CollapsingBorderModelEyeCatching (in the layout package) to CommonBorderPaddingBackground

Re: Automatic column widths in fop

2005-08-28 Thread Manuel Mall
On Sun, 28 Aug 2005 10:15 pm, Andreas L Delmelle wrote: On Aug 28, 2005, at 15:57, Manuel Mall wrote: This is just a clarification question to those in the know. In HTML when specifying a table browsers usually choose the smallest width without causing unforced breaks in columns

Broken padding on table-cells

2005-08-28 Thread Manuel Mall
Padding on table-cells is currently broken. The sample fo file below demonstrates the problem. I think I know the cause and the fix but would like confirmation: Am I correct in saying that in the collapsing border model any padding is not part of the collapsing, i.e. it only applies to the

Re: Broken padding on table-cells

2005-08-29 Thread Manuel Mall
- no slur intended. I ended up adding the original padding to the resolved CommonBorderAndPadding structure and all is fine now (as far as padding on these table cells goes). On 28.08.2005 19:38:39 Andreas L Delmelle wrote: On Aug 28, 2005, at 18:17, Manuel Mall wrote: Padding on table-cells

Background properties on fo:table-body

2005-08-29 Thread Manuel Mall
Am I correct in saying that fop trunk currently doesn't support background properties on fo:table-body (although our compliance table says full support -:))? Manuel

Re: Wrongly positioned image in PDF renderer

2005-08-29 Thread Manuel Mall
). I can fix/review the renderers if someone provides test cases though. OK, I'll keep that on my todo list for the time being. Can you please document what other problems related to background positioning you found? On 29.08.2005 08:08:29 Manuel Mall wrote: While testing / implementing padding

Re: Background properties on fo:table-body

2005-08-29 Thread Manuel Mall
On Mon, 29 Aug 2005 04:19 pm, Jeremias Maerki wrote: Oops. Yes, table-body doesn't paint any backgrounds, yet. Just for completeness: table-header and table-footer are in fop treated like table-body and are therefore also missing background property support. On 29.08.2005 09:52:40 Manuel Mall

Percentages on region margins

2005-08-29 Thread Manuel Mall
I am trying to figure out on which base value to apply the margin=5% on the fo:region-body (see fragment below): fo:simple-page-master master-name=normal page-width=5in page-height=5in margin=5% fo:region-body margin=5% / fo:region-before extent=5% / ... The margin in the

Re: Percentages on region margins

2005-08-29 Thread Manuel Mall
-master and its subordinate elements in which case margins on regions would be resolved relative to the page-width/height. On 29.08.2005 13:18:59 Manuel Mall wrote: I am trying to figure out on which base value to apply the margin=5% on the fo:region-body (see fragment below): fo:simple

Re: Percentages on region margins

2005-08-29 Thread Manuel Mall
On Mon, 29 Aug 2005 11:28 pm, Jeremias Maerki wrote: On 29.08.2005 17:18:18 Manuel Mall wrote: On Mon, 29 Aug 2005 08:20 pm, Jeremias Maerki wrote: You probably missed the following: 7.10.1 margin-top says for percentages: The percentage is calculated with respect to the width

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

2005-08-29 Thread Manuel Mall
Finn, thanks a lot for looking at this. On Tue, 30 Aug 2005 03:19 am, Finn Bock wrote: [Jeremias Maerki on ] Yeah: Wow! Finn, you're the specialist here. Can you take the lead on this one? I'm hardly a specialist on the layout system, and that is where a good sized part of Manuels patch

Re: svn commit: r264120 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/area/ test/java/org/apache/fop/layoutengine/ test/layoutengine/ test/layoutengine/testcases/

2005-08-29 Thread Manuel Mall
on the same problem. Working on the same class/test/web page... to address something different is not an issue for me and at times unavoidable as you said. Manuel On 29.08.2005 17:11:26 Manuel Mall wrote: Jeremias, Re - this and all the related other svn updates. Unfortunately we

Margins and writing mode

2005-08-29 Thread Manuel Mall
If I set the writing mode on a page master to rl (arabic/hebrew) and than define margin-left and right on the region body where are these margins suppose to appear on the output device, i.e. would margin-left still be on the left side of the paper and margin-right on the right side? A sample

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

2005-08-29 Thread Manuel Mall
On Tue, 30 Aug 2005 08:27 am, Manuel Mall wrote: Finn, thanks a lot for looking at this. On Tue, 30 Aug 2005 03:19 am, Finn Bock wrote: [Jeremias Maerki on ] snip/ I'm hardly a specialist on the layout system, and that is where a good sized part of Manuels patch is, but in the property

Truncation vs rounding

2005-08-30 Thread Manuel Mall
In the property system most numeric values are stored and operated upon as double's. However, once we get to the LMs they only deal in int's. Currently the conversion between the double and the int is a simple typecast which equates to truncation. It that the right thing to do or shall we

Re: Margins and writing mode

2005-08-30 Thread Manuel Mall
about getting the basic page, viewport, region geometry right not the details of the BIDI algorithm, glyphs, fonts, mirroring, On 30.08.2005 07:02:57 Manuel Mall wrote: If I set the writing mode on a page master to rl (arabic/hebrew) and than define margin-left and right on the region

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

2005-08-30 Thread Manuel Mall
On Tue, 30 Aug 2005 04:05 pm, Finn Bock wrote: [Manuel] Agree, and I have a solution for that ready to go. I think this deserves some further comment / discussion. One, IMO important, reason I want to do the evaluation during the FO parsing stage is that once we are in the LMs we lost

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

2005-08-30 Thread Manuel Mall
On Tue, 30 Aug 2005 04:16 pm, Manuel Mall wrote: On Tue, 30 Aug 2005 04:05 pm, Finn Bock wrote: [Manuel] Agree, and I have a solution for that ready to go. I think this deserves some further comment / discussion. One, IMO important, reason I want to do the evaluation during the FO

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

2005-08-30 Thread Manuel Mall
On Tue, 30 Aug 2005 08:43 pm, Victor Mote wrote: Manuel Mall wrote: PS: I can imagine Victor smiling now :-) : I told you so that not leaving all property resolution to the LM stage is going to cause trouble. Trust me, I'm not smiling. As one of our U.S. Presidents was known for saying

Re: Error loading GIF image using JAI in FOP Trunk (was: Error w hile processing a PDF - OK)

2005-08-30 Thread Manuel Mall
Stephen, thanks for pointing this out (again). I'll post a patch to fix this. Manuel On Wed, 31 Aug 2005 07:02 am, Stephen Denne wrote: Regarding a fop-users email mentioning: com/sun/media/jai/codec/FileCacheSeekableStream Reminded me of something I encountered recently: In my brief

Re: Margins and writing mode

2005-08-30 Thread Manuel Mall
of the other writing modes. For me personally, the main reason is the lack of knowledge about non-latin languages. On 30.08.2005 07:02:57 Manuel Mall wrote: If I set the writing mode on a page master to rl (arabic/hebrew) and than define margin-left and right on the region body where

Re: Percentages on region margins

2005-08-30 Thread Manuel Mall
On Mon, 29 Aug 2005 11:31 pm, Manuel Mall wrote: On Mon, 29 Aug 2005 11:28 pm, Jeremias Maerki wrote: On 29.08.2005 17:18:18 Manuel Mall wrote: On Mon, 29 Aug 2005 08:20 pm, Jeremias Maerki wrote: You probably missed the following: 7.10.1 margin-top says for percentages

Re: Wrongly positioned image in PDF renderer

2005-08-30 Thread Manuel Mall
to the top of the box. http://people.apache.org/~jeremias/fop/cell-back1.zip On 29.08.2005 10:33:56 Manuel Mall wrote: OK, I'll keep that on my todo list for the time being. Can you please document what other problems related to background positioning you found? Jeremias Maerki Manuel

Re: Let's write the release plan for the first preview release

2005-08-30 Thread Manuel Mall
Excellent - I like the sound of it :-). Personally, after having now used the trunk a bit and seeing the test cases, etc., I would be a bit bolder and go for a name like 1.0 alpha or 1.0EA (I think that's the terminology Sun is using for unstable early releases). The big disclaimers still

Re: Let's write the release plan for the first preview release

2005-08-31 Thread Manuel Mall
on anything outside. Just personally I like some focus at times and I think this project is at a stage were it would benefit as well - only temporarily though as IMO (some form of) anarchy is important to keep these open source volunteer based projects going. On 31.08.2005 05:09:40 Manuel Mall wrote

Re: [Xmlgraphics-fop Wiki] Update of ReleasePlanFirstPR by ChrisBowditch

2005-08-31 Thread Manuel Mall
Chris, do you really think that FOray font integration is a prerequisite for this release? I would have thought its more of a nice to have but not a requirement for this release. Manuel On Wed, 31 Aug 2005 09:00 pm, Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or

Re: svn commit: r265578 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/extensions/svg/SVGElement.java

2005-08-31 Thread Manuel Mall
I am getting a compile error: compile-java: [javac] Compiling 426 source files to /home/mm/fop-ref/build/classes [javac] /home/mm/fop-ref/src/java/org/apache/fop/fo/extensions/svg/SVGElement.java:89: cannot find symbol [javac] symbol : method setDocumentURI(java.lang.String)

Re: svn commit: r265577 [1/5] - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/area/ src/java/org/apache/fop/datatypes/ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/expr/ src/java/org/ap

2005-08-31 Thread Manuel Mall
: 265577 URL: http://svn.apache.org/viewcvs?rev=265577view=rev Log: Bugzilla #36379: Revised percentage resolution system. Submitted by: Manuel Mall mm.at.arcus.com.au Slightly modified to avoid early evaluation of getValue(). snip/ Added: xmlgraphics/fop/trunk/src/java/org/apache

Re: svn commit: r265051 - in /xmlgraphics/fop/trunk/test: layoutengine/disabled-testcases.txt layoutengine/testcases/external-graphic4.xml resources/images/big-image.png

2005-08-31 Thread Manuel Mall
We may have a case of the lost update problem here. My percentage resolution patch which Finn kindly applied provided a testcase external-graphic4.xml which I believe has overwritten the version committed by Jeremias. Manuel On Wed, 31 Aug 2005 10:33 pm, [EMAIL PROTECTED] wrote: Author:

Re-organising layout engine testcases?

2005-09-01 Thread Manuel Mall
We now have over 200 layout engine test cases in the repository which is great. However, with this ever growing number I wonder if we should put some more structure to it. There is a real chance that we get more and more duplication just because people wouldn't know which tests are doing what

Re: Re-organising layout engine testcases?

2005-09-01 Thread Manuel Mall
On Thu, 1 Sep 2005 02:39 pm, Jeremias Maerki wrote: On 01.09.2005 06:04:45 Manuel Mall wrote: We now have over 200 layout engine test cases in the repository which is great. Wow! I just hope nobody holds a grudge against me for introducing that facility and pushing people to use

e-g with padding and borders

2005-09-01 Thread Manuel Mall
I think the area tree viewport generated by the current version for an e-g with padding and borders is wrong. Here is the fo snippet (from external-graphic_border_padding.xml): fo:external-graphic src=../../resources/images/bgimg300dpi.jpg border=solid 5pt padding=5pt

Re: e-g with padding and borders

2005-09-01 Thread Manuel Mall
and the test. On 01.09.2005 15:53:46 Manuel Mall wrote: I think the area tree viewport generated by the current version for an e-g with padding and borders is wrong. Here is the fo snippet (from external-graphic_border_padding.xml): fo:external-graphic src=../../resources/images

Re: e-g with padding and borders

2005-09-01 Thread Manuel Mall
I have a follow-up question on this. If we have something as simple(?) as this: fo:block background-color=orange fo:external-graphic src=../../resources/images/bgimg300dpi.jpg border=solid 5pt padding=5pt background-color=white/ /fo:block would you expect

Re: e-g with padding and borders

2005-09-01 Thread Manuel Mall
the one of a block area. See 4.3.2. Geometric Definitions in the 1.0 spec. Border and padding for an inline area seem to be outside the allocation rectangle in before and after directions. Interesting. On 01.09.2005 17:29:50 Manuel Mall wrote: I have a follow-up question

Re: e-g with padding and borders

2005-09-02 Thread Manuel Mall
around each inlineblockparent (one for each block inside the inline)? I'm not sure judging from the specification. HTH On 02.09.2005 07:21:49 Manuel Mall wrote: Vincent, Jeremias, thanks for the clarification. After looking just a little bit more into it it appears

Re: e-g with padding and borders

2005-09-02 Thread Manuel Mall
for an inline area seem to be outside the allocation rectangle in before and after directions. Interesting. On 01.09.2005 17:29:50 Manuel Mall wrote: I have a follow-up question on this. If we have something as simple(?) as this: fo:block background-color=orange fo:external-graphic

Re: e-g with padding and borders

2005-09-02 Thread Manuel Mall
On Fri, 2 Sep 2005 10:01 pm, Jeremias Maerki wrote: On 02.09.2005 15:38:41 Manuel Mall wrote: The problems reported here with e-g and padding / borders apply equally to i-f-o. It's not too hard to fix. While doing this I noticed that the code for the i-f-o LM and e-g LM is logically

regions and writing-mode

2005-09-03 Thread Manuel Mall
This is (again) more of a clarifying question as I am looking in that area of the code and I think its incorrect: Am I correct in saying: The position of the before/after/start/end regions on the output media is relative to the writing-mode and reference orientation on the simple-page-master they

Re: e-g with padding and borders

2005-09-04 Thread Manuel Mall
as well at the beginning and end of each intermediate line. Any suggestions how this can/should be integrated into the linebreaking algorithm? Manuel On Fri, 2 Sep 2005 03:29 pm, Manuel Mall wrote: Allright, I will have a go at this and scream for help if I get stuck. Step 1 would be to get

Re: e-g with padding and borders

2005-09-05 Thread Manuel Mall
On Mon, 5 Sep 2005 03:08 pm, Manuel Mall wrote: Jeremias, thanks for your patience in answering my questions. On Mon, 5 Sep 2005 02:51 pm, Jeremias Maerki wrote: On 04.09.2005 16:34:35 Manuel Mall wrote: snip/ Another question for the Knuth experts. It appears the inline LMs don't

Re: e-g with padding and borders

2005-09-05 Thread Manuel Mall
? I'll see if I can get my hand on the book in the university library here (btw - I am in Perth - Western Australia). In the meantime I'll stick with the discard model which happens to be the default anyway. Manuel On 05.09.2005 14:52:23 Manuel Mall wrote: On Mon, 5 Sep 2005 03:08 pm

fo:inline bpd

2005-09-05 Thread Manuel Mall
Currently fop sets the bpd of areas created from fo:inlines to to line-height of the line the area appears in. For example: fo:block font-size=10ptSome text fo:inline font-size=8ptsmaller text/fo:inline/fo:block The inline parent area created for the fo:inline will be given a bpd of 12pt,

Re: fo:inline bpd

2005-09-06 Thread Manuel Mall
the dimensions of the line segment the Inline LM is suppose to construct. It may actually be appropriate to do that in the Line LM as it already has the relevant logic. But still we would need an interface to get this across to the Inline LM. On 06.09.2005 06:57:06 Manuel Mall wrote: Currently fop

Re: e-g with padding and borders

2005-09-06 Thread Manuel Mall
Luca, thanks for taking the time to respond. Comments inline. On Tue, 6 Sep 2005 05:26 pm, Luca Furini wrote: Manuel Mall wrote: Next problem: border conditionality - how do I model that with the Knuth approach? At the time I add the Border/Padding start/end boxes we don't have line

Re: e-g with padding and borders

2005-09-06 Thread Manuel Mall
Luca, thanks great stuff - that gives me a lot to work with. Manuel On Tue, 6 Sep 2005 06:48 pm, Luca Furini wrote: Manuel Mall wrote: These two paragraphs confuse me - sorry. My understanding was: discard = start/end borders/padding only at the start and end of the whole fo:inline

Re: Line LM, Inline LM and LAST_AREA

2005-09-06 Thread Manuel Mall
case I am only interested in inline areas. However, it seems no solution has yet been found for this issue. I'll keep looking then. Manuel On Tue, 6 Sep 2005 06:46 pm, Luca Furini wrote: Manuel Mall wrote: But if we have a long fo:inline stretching multiple lines this seem to give the wrong

Re: Line LM, Inline LM and LAST_AREA

2005-09-06 Thread Manuel Mall
consumption on LMs that don't need the position indexes. Maybe this infrastructure should be extracted into its own class and used by the LMs that need it. On 06.09.2005 14:33:07 Manuel Mall wrote: Jeremias any problems if I push this down from BlockStacking LM into Abstract LM so I can make use

Combined compound and shorthand property specs

2005-09-07 Thread Manuel Mall
Is the following legal:? fo:inline border=solid 1pt red border-start-width.conditionality=retain border-end-width.conditionality=retain padding=1pt padding-start.conditionality=retain padding-end.conditionality=retain What seems to happen is that for borders it works fine, that is

Re: Combined compound and shorthand property specs

2005-09-07 Thread Manuel Mall
On Wed, 7 Sep 2005 03:48 pm, Finn Bock wrote: [Manuel] Is the following legal:? fo:inline border=solid 1pt red border-start-width.conditionality=retain border-end-width.conditionality=retain padding=1pt padding-start.conditionality=retain

  1   2   3   4   >