Re: Error output of junit-layout-standard
Some lazyness on my side. It's fixed now: http://svn.apache.org/viewvc?rev=752010view=rev http://svn.apache.org/viewvc?rev=752011view=rev There was no error because it's classified as non-fatal. Anyway, it pointed to a missing base directory and an incomplete IFTester class. And the stacktrace was printed because the image exceptions were not routed into the event subsystem. Just for the curious: it was basic-link_background-image.xml. Basically, if there's anything still left in the [junit] - Standard Error - part, that means there is some log output that is still not routed through the event subsystem. So there are still a few nits to fix here. More when I have more time. On 09.03.2009 21:28:03 Andreas Delmelle wrote: Hi all Just updated my local sandbox, and noticed an error in the build log that I didn't quite expect: [junit] - Standard Error - [junit] Mar 9, 2009 9:00:01 PM org.apache.fop.area.AreaTreeParser $Handler setTraits [junit] SEVERE: Background image not available: ../../resources/ images/bgimg300dpi.jpg [junit] java.io.FileNotFoundException: Image not found: ../../ resources/images/bgimg300dpi.jpg ... [junit] at org.apache.fop.intermediate.IFTester.createIF(IFTester.java:145) [junit] at org.apache.fop.intermediate.IFTester.doIFChecks(IFTester.java:163) Does anyone else get this? I haven't investigated yet which testcase it points to, so before I start digging, if this rings a bell... It doesn't cause a failure, though. Build successful. Cheers Andreas Jeremias Maerki
AFP: Font access
At the moment, AFP fonts are exclusively accessed by local file paths (plus some special code for accessing JAR resources). But this is different to what we have for other fonts where we can use URIs and the FontManager's base URI/URL. I'm currently working on changing that. But this will have a consequence for current users of AFP output: On Windows, filenames are case-insensitive. Moving to URIs this case-insensitivity falls away. The resource names in the configuration will have to match the filename case to be found. What I can do is check for the all uppercase and all lowercase variants if the original resource name isn't found. That should solve most possible mismatches. But still, C0gsl10 will not match C0GSL10. So that introduces a semantic change. (It's similar to what we do in Type1FontLoader when finding the AFM font that belongs to the PFB font.) At the moment, you set the path attribute on an AFP font: http://xmlgraphics.apache.org/fop/trunk/output.html#afp-configuration I'm proposing to introduce an attribute base-uri as a replacement. This base URI can be relative itself and will be resolved against the font base URI/URL. That alone is no problem, but the decision here is how to provide backwards-compatibility for the path attribute. In the code I've already changed locally I'm simply mapping path to base-uri (just a few lines) and I'm switching all AFP font loading code from String to java.net.URI. But exactly that will be causing the semantic change mentioned above. The alternative would be to support both approaches at the same time but since this goes through many classes, it would cause quite a bit of additional code just for handling a corner case, and I'd like to avoid that and to keep the code as clean as possible. If anyone disagrees with that please speak up. Thanks, Jeremias Maerki
Re: AFP: Font access
Hmm, false alarm. Despite using URIs, case mismatches with File URI/URLs on Windows don't matter. Good to know. On 10.03.2009 10:27:01 Jeremias Maerki wrote: At the moment, AFP fonts are exclusively accessed by local file paths (plus some special code for accessing JAR resources). But this is different to what we have for other fonts where we can use URIs and the FontManager's base URI/URL. I'm currently working on changing that. But this will have a consequence for current users of AFP output: On Windows, filenames are case-insensitive. Moving to URIs this case-insensitivity falls away. The resource names in the configuration will have to match the filename case to be found. What I can do is check for the all uppercase and all lowercase variants if the original resource name isn't found. That should solve most possible mismatches. But still, C0gsl10 will not match C0GSL10. So that introduces a semantic change. (It's similar to what we do in Type1FontLoader when finding the AFM font that belongs to the PFB font.) At the moment, you set the path attribute on an AFP font: http://xmlgraphics.apache.org/fop/trunk/output.html#afp-configuration I'm proposing to introduce an attribute base-uri as a replacement. This base URI can be relative itself and will be resolved against the font base URI/URL. That alone is no problem, but the decision here is how to provide backwards-compatibility for the path attribute. In the code I've already changed locally I'm simply mapping path to base-uri (just a few lines) and I'm switching all AFP font loading code from String to java.net.URI. But exactly that will be causing the semantic change mentioned above. The alternative would be to support both approaches at the same time but since this goes through many classes, it would cause quite a bit of additional code just for handling a corner case, and I'd like to avoid that and to keep the code as clean as possible. If anyone disagrees with that please speak up. Thanks, Jeremias Maerki Jeremias Maerki
DO NOT REPLY [Bug 46828] New: [PATCH] Enabling area tree caching from FOUserAgent
https://issues.apache.org/bugzilla/show_bug.cgi?id=46828 Summary: [PATCH] Enabling area tree caching from FOUserAgent Product: Fop Version: 1.0dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: lae...@ima.it The attached patch fix some bugs in area tree caching and allow to enable caching from FOUserAgent. We use it in production without problems and would be nice to see it included in the next stable release. I know that few users would benefit from this patch, but at the same time it seems harmless to me. Patch details: * CachedRenderPagesModel.java: page.toString() was producing a bad file name, in particular all objects were written in the same .ser file and Fop wasn't able to read back those objects when there was too much pages * InlineArea.java: need to be serializable * AbstractLayoutManager.java, TableCellLayoutManager.java: just free references to the objects serialized -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46828] [PATCH] Enabling area tree caching from FOUserAgent
https://issues.apache.org/bugzilla/show_bug.cgi?id=46828 --- Comment #1 from Laera Dario lae...@ima.it 2009-03-10 07:26:17 PST --- Created an attachment (id=23366) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23366) Bug fixes and FOUserAgent facility -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46826] reference-orientation treated as an inherited property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826 --- Comment #4 from Chris Bowditch bowditch_ch...@hotmail.com 2009-03-10 07:50:43 PST --- Andreas - I have a question about your proposed change. Its really only for my understanding: Suppose you have something like: fo:simple-page-master name=a4 fo:region-body reference-orientation=90/ /fo:simple-page-master .. fo:flow flow-name=xsl-region-body fo:blockText1 fo:block-container fo:blockText2/fo:block /fo:block-container /fo:block /fo:flow The current behaviour of this is that both Text1 and Text2 will be rotated. After your change can we expect Text1 and Text2 to have a different orientation? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: AFP: Font access
Changes committed: http://svn.apache.org/viewvc?rev=752133view=rev On 10.03.2009 14:22:03 Jeremias Maerki wrote: Hmm, false alarm. Despite using URIs, case mismatches with File URI/URLs on Windows don't matter. Good to know. On 10.03.2009 10:27:01 Jeremias Maerki wrote: At the moment, AFP fonts are exclusively accessed by local file paths (plus some special code for accessing JAR resources). But this is different to what we have for other fonts where we can use URIs and the FontManager's base URI/URL. I'm currently working on changing that. But this will have a consequence for current users of AFP output: On Windows, filenames are case-insensitive. Moving to URIs this case-insensitivity falls away. The resource names in the configuration will have to match the filename case to be found. What I can do is check for the all uppercase and all lowercase variants if the original resource name isn't found. That should solve most possible mismatches. But still, C0gsl10 will not match C0GSL10. So that introduces a semantic change. (It's similar to what we do in Type1FontLoader when finding the AFM font that belongs to the PFB font.) At the moment, you set the path attribute on an AFP font: http://xmlgraphics.apache.org/fop/trunk/output.html#afp-configuration I'm proposing to introduce an attribute base-uri as a replacement. This base URI can be relative itself and will be resolved against the font base URI/URL. That alone is no problem, but the decision here is how to provide backwards-compatibility for the path attribute. In the code I've already changed locally I'm simply mapping path to base-uri (just a few lines) and I'm switching all AFP font loading code from String to java.net.URI. But exactly that will be causing the semantic change mentioned above. The alternative would be to support both approaches at the same time but since this goes through many classes, it would cause quite a bit of additional code just for handling a corner case, and I'd like to avoid that and to keep the code as clean as possible. If anyone disagrees with that please speak up. Thanks, Jeremias Maerki Jeremias Maerki Jeremias Maerki
Proposal: FOUserAgent.getFontBaseURL() deprecation?
While working on URI resolution for AFP fonts, I've stumbled over FOUserAgent.getFontBaseURL(). I found that a strange thing now that we have the FontManager (attached to the FopFactory). Well, getFontBaseURL () has been there for some time but FOUserAgent.setFontBaseURL was introduced by: http://svn.eu.apache.org/viewvc?view=revrevision=542237 Looks like I didn't really notice that when I processed that patch. Anyway, getFontBaseURL() is only called once by DefaultFontResolver. I don't really see the benefit to have a per-FOUserAgent font base URL. So I would like to propose to deprecate get/setFontBaseURL() on FOUserAgent. The attached patch illustrated what I'd like to do. I think: if we ever get to the point where we can refactor the font subsystem so the fonts are only parsed once by the font manager and not per rendering run, the font base URL on the user agent level will not make any sense anyway. Sensible? Or am I missing anything with the font base URL on the user agent level? ---===--- BTW, while testing the AFP font stuff I noticed that it's currently not possible to use a non-file URL as font base URL. I get a MalformedURLException in FOURIResolver.checkBaseURL(). That's not the idea. I'm going to look into that. Jeremias Maerki FOUserAgent-getFontBaseURL-Deprecation.diff Description: Binary data
DO NOT REPLY [Bug 46826] reference-orientation treated as an inherited property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826 --- Comment #5 from Andreas L. Delmelle adelme...@apache.org 2009-03-10 10:43:40 PST --- (In reply to comment #4) Andreas - I have a question about your proposed change. Its really only for my understanding: Suppose you have something like: snip / The current behaviour of this is that both Text1 and Text2 will be rotated. After your change can we expect Text1 and Text2 to have a different orientation? I think not, and IIC, this should not be the case. Nevertheless, I recently bumped into precisely that effect when nesting block-containers: the inner block-container would inherit the value of the outer block-container, and thus be rotated another 90 degrees relative to the outer b-c reference-area. In the case you present, the region-body is rotated by 90 degrees. So, the flow-reference-area will be rotated by 90 degrees with respect to the page-reference-area. The block-container, having reference-orientation 0 relative to the flow-reference-area, will also be rotated by 90 degrees relative to the page. Result: with normal A4 dimensions (210x297), we will get a portrait page, with both Text1 and Text2 appearing below each other in the page's lower-left corner, rotated by the same amount wrt the page. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46826] reference-orientation treated as an inherited property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826 --- Comment #7 from Andreas L. Delmelle adelme...@apache.org 2009-03-10 11:48:16 PST --- Forget the patch for the moment. Still too cheap. Just ran some more tests, and after the change: - the content is rotated OK, but... - the clipping rectangle is off (rotated yet another 90 degrees) All the tests I could have known it was not going to be that easy. ;-) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46826] reference-orientation treated as an inherited property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826 --- Comment #8 from Andreas L. Delmelle adelme...@apache.org 2009-03-10 12:38:19 PST --- Created an attachment (id=23367) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23367) PDF result before and after the patch Sorry, previous remark was too fast again. Redoing the test after reverting the changes shows no difference. In attach, the PDF result for simple-page-master_reference-orientation.xml The layout checks pass, but the issue did appear to exist before... The clipping rectangle is rotated once too many, and the offset due to the page-margins is taken into account twice. Seems to me the region-reference CTM should be an identity CTM, no? (identical to the -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Error output of junit-layout-standard
On 10 Mar 2009, at 09:02, Jeremias Maerki wrote: Some lazyness on my side. It's fixed now: http://svn.apache.org/viewvc?rev=752010view=rev http://svn.apache.org/viewvc?rev=752011view=rev Heh, no biggie. Thanks for the swift response and the fix. Cheers Andreas
DO NOT REPLY [Bug 46828] [PATCH] Enabling area tree caching from FOUserAgent
https://issues.apache.org/bugzilla/show_bug.cgi?id=46828
--- Comment #2 from Andreas L. Delmelle adelme...@apache.org 2009-03-10
14:53:00 PST ---
Thanks for the patch. I'm going to apply it, with just one change.
Not sure if anyone else agrees, but the modification to AbstractLayoutManager
seems to belong in BlockStackingLayoutManager...?
It seems cleaner to override notifyEndOfLayout() in BlockStackingLM, and depend
on the runtime type-checking to trigger the correct implementation, instead of
forcing the explicit instanceof check on all concrete subclasses.
In BlockStackingLM:
/** {...@inheritdoc} */
protected void notifyEndOfLayout() {
super.notifyEndOfLayout();
// Free memory of the area tree
this.parentArea = null;
}
Should have the exact same effect, but the change is then made only to the
affected class source.
(I'm not too happy with the explicit references to FlowLM and PageSequenceLM a
bit further down --I put them there myself, though :-S At any rate, references
to concrete subclasses in an abstract superclass just always smell a bit
strange...)
BTW: if using caching is beneficial, we may want to consider defaulting to
'true'. Opinions?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
