Re: Suggestion: refactoring property access in the FO tree?
Hi Andreas,
I have little knowledge of the FO tree construction, so I'll perhaps
make naive questions and remarks. I write them in the hope they will
trigger further thoughts.
Andreas L Delmelle a écrit :
Hi,
Just an idea that popped in my head. I was thinking of the access to a
FONode's properties from the layoutengine, and it became apparent to me
that ATM the approach is not too flexible: each subclass has its own
little set of private instance methods and public accessors. This makes
it hard to implement new properties or deal with extension properties in
a generic way.
Also, that causes the same code to be replicated in every class; for
example each object for which the margin properties apply will have (1)
a CommonMarginBlock field; (2) a commonMarginBlock =
pList.getMarginBlockProps(); line in the bind method. This replication
of code is unfortunate as it artificially increases the codebase size,
is more error-prone and more difficult to maintain.
In ancient times, each FO had a full PropertyList, so the properties
could be queried via a generic get(PROPERTY_ID) accessor that was simply
a proxy to the PropertyList's corresponding get(). This was, however, a
much less efficient approach than what we currently have.
To be sure I understand: each object had the very same list of
properties, with null values for the properties wich were not applicable
to it? And the loss of efficiency was due to the indirection caused by
the generic get(PROPERTY_ID) I guess?
My suggested best-of-both-worlds would be the addition of (at least) one
new type, which would store the applicable properties for a FO.
Starting with an interface:
public interface FOProperties {
Property get(int);
Property get(String);
}
Each of the particular FO classes can then define its own
implementation, which stores the applicable properties and maybe, for
some FOs (like FOText!), this implementation can simply search the
ancestors, instead of having to allocate space for properties that are
always identical and can't be specified anyway...
Hmmm. My understanding of the whole thing is still a bit vague, but
wouldn't that lead to the same code replication as we have now? I'm
wondering if it's not possible to define a restricted number of
implementations of this interface, each applying to a whole set of
similar FOs. Or use object composition: there would be objects dealing
with a particular set of properties (say, border/padddin/background),
and each FO for which that set applies would be composed of the
corresponding object.
Perhaps the flyweight pattern could apply here: only one object for each
set of properties, initializing the correct fields in the FObj. With
some means to automagically wire everything by using marker interfaces
or whatever.
As I said my ideas are still all pretty vague... Also, does anyone have
knowledge about aspect programming? I've the feeling that could apply
quite well here.
The downside would be the loss in convenience, for instance, where we
now have individual accessors returning a Length, LengthRange,
Numeric... Not sure how I would address this, yet. :/
I'm not sure of what you mean? The same property can be accessed in
different ways?
If anyone has suggestions, feedback is welcome.
I hope what I wrote makes sense :-\
Cheers,
Vincent
Off-document items in last PageSequence
Hi all, As the (almost) last part of my basic-links job, I've implemented bookmarks handling in XMLRenderer and AreaTreeParser. What puzzled me is that the bookmark tree wound up in the XML output as the last child of the last PageSequence, instead of after the last PageSequence. I don't understand how this can happen, because AreaTreehandler.endDocument() calls finishPrevPageSequence() before adding the bookmark tree. It doesn't affect the functonality, but it doesn't seem right to me that end-of-doc off-document items should be children of a particular PageSequence. Should I try to find out what's going on and provide a fix (if possible), or is this placement as intended? Kind regards, Paul Vinkenoog
LayoutEngineTestSuite: disabled and start-with properties
Guys,
When running the layoutengine testsuite, it is possible to use several
properties to select the testcases you want to run. As a reminder
everything is explained here:
http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests
You can exclude the disabled testcases to be run by using the
fop.layoutengine.disabled property. But this property can't currently be
used together with the fop.layoutengine.starts-with property.
I think this should be the case, as I recently felt that need. The
modification is very simple (attached diff) and wouldn't prevent the
current behavior to occur (you just have to not specify the disabled
property).
Anyone against me doing the change?
BTW, I know I already told it, but I'm falling in love with that
testsuite...
Vincent
Index: test/java/org/apache/fop/layoutengine/LayoutEngineTestSuite.java
===
--- test/java/org/apache/fop/layoutengine/LayoutEngineTestSuite.java (révision 522536)
+++ test/java/org/apache/fop/layoutengine/LayoutEngineTestSuite.java (copie de travail)
@@ -140,6 +140,7 @@
} else if (startsWith != null) {
filter = new PrefixFileFilter(startsWith);
filter = new AndFileFilter(filter, new SuffixFileFilter(.xml));
+filter = decorateWithDisabledList(filter);
} else {
filter = new SuffixFileFilter(.xml);
filter = decorateWithDisabledList(filter);
DO NOT REPLY [Bug 41995] New: - [PATCH] Barcode Support for AFP Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41995. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41995 Summary: [PATCH] Barcode Support for AFP Renderer Product: Fop Version: all Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] The attached patch provides barcode support for the AFP Renderer, defining the barcode using BCOCA (Bar Code Object Content Architecture) within the AFP datastream. The patch uses a specific BCOCA extension, although this could easily be change to a generic extension to barcodes in different output formats. The extension nanespace is xmlns:bcoca=http://xmlgraphics.apache.org/fop/extensions/afp/bcoca; I have created a seperate package org.apache.fop.barcode which contains the code for the barcode configuration and dimension calculations, this is based largely on the excellent Barcode4J code by Jeremias Maerki, except that I have removed the aspects not required for AFP such as the generation of the barcode. So far I have only implemented Code39, PDF417 and POSTNET. Ideally this needs to be re-organized to provide generic barcode support, although this would require closer integration with Barcode4J. This package does not contain any AFP specifics and these are handled in the bcoca packages. Two files are attached, the patch file and a seperate zip containing the new files. Rgds, Pete Townsend -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 41995] - [PATCH] Barcode Support for AFP Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41995. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41995 --- Additional Comments From [EMAIL PROTECTED] 2007-03-30 08:10 --- Created an attachment (id=19849) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19849action=view) AFP Barcode Patch -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 41995] - [PATCH] Barcode Support for AFP Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41995. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41995 --- Additional Comments From [EMAIL PROTECTED] 2007-03-30 08:11 --- Created an attachment (id=19850) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19850action=view) New files associated to the patch -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Suggestion: refactoring property access in the FO tree?
On Mar 30, 2007, at 11:21, Vincent Hennebert wrote: Hi Vincent, I have little knowledge of the FO tree construction, so I'll perhaps make naive questions and remarks. I write them in the hope they will trigger further thoughts. That was the general idea. :-) Besides, people who are not all too familiar yet with that part of the code are sometimes more likely to offer helpful hints (as their thinking has not yet been contaminated ;-)) snip / Also, that causes the same code to be replicated in every class; for example each object for which the margin properties apply will have (1) a CommonMarginBlock field; (2) a commonMarginBlock = pList.getMarginBlockProps(); line in the bind method. This replication of code is unfortunate as it artificially increases the codebase size, is more error-prone and more difficult to maintain. Indeed! Yet another reason pro refactoring in that area. In ancient times, each FO had a full PropertyList, so the properties could be queried via a generic get(PROPERTY_ID) accessor that was simply a proxy to the PropertyList's corresponding get(). This was, however, a much less efficient approach than what we currently have. To be sure I understand: each object had the very same list of properties, with null values for the properties wich were not applicable to it? Errm... yes, if what you mean by 'the very same' is 'a different instance of the very same type'. Each FObj instance had its very own instance of the same PropertyList type. And the loss of efficiency was due to the indirection caused by the generic get(PROPERTY_ID) I guess? The biggest inefficiency was the space that these lists consume. They allocate space for an array with a number of elements equal to the number of /possible/ properties, effectively wasting space in case of FOs to which only a handful properties apply. On top of that, this space was not reclaimed until very late in the process, whereas now, the PropertyLists and their backing arrays in most cases can be garbage-collected right after endElement(). A FO to which only three properties apply will currently have only three instance variables corresponding to those properties. In the old architecture, it would have one PropertyList member, containing an array that could store some 250 Property instances, but only three elements were actually in use... The inefficiency caused by the indirection I would consider to be a small but necessary price to pay for an increased amount of flexibility and extensibility. snip / Each of the particular FO classes can then define its own implementation, which stores the applicable properties and maybe, for some FOs (like FOText!), this implementation can simply search the ancestors, instead of having to allocate space for properties that are always identical and can't be specified anyway... Hmmm. My understanding of the whole thing is still a bit vague, but wouldn't that lead to the same code replication as we have now? I'm wondering if it's not possible to define a restricted number of implementations of this interface, each applying to a whole set of similar FOs. Good point! Or use object composition: there would be objects dealing with a particular set of properties (say, border/padddin/background), and each FO for which that set applies would be composed of the corresponding object. Perhaps the flyweight pattern could apply here: only one object for each set of properties, initializing the correct fields in the FObj. With some means to automagically wire everything by using marker interfaces or whatever. Also fine suggestions. I'm going to chew on these a bit more. As I said my ideas are still all pretty vague... Also, does anyone have knowledge about aspect programming? I've the feeling that could apply quite well here. Just been reading up on AOSD, and it does indeed seem to be fitting in here. The downside would be the loss in convenience, for instance, where we now have individual accessors returning a Length, LengthRange, Numeric... Not sure how I would address this, yet. :/ I'm not sure of what you mean? The same property can be accessed in different ways? What I mean is that right now, the bind() method already takes care of getting the right type of Property. pList.get(PROPERTY_ID).getLengthRange() for instance... An accessor getInlineProgressionDimension(), for example, returns a LengthRange (not a Property). This treatment would obviously have to be moved or performed somewhere else, if a generic get() would always return an instance of type Property. If anyone has suggestions, feedback is welcome. I hope what I wrote makes sense :-\ It did. Cheers, Andreas
Re: Off-document items in last PageSequence
I wrote: As the (almost) last part of my basic-links job, I've implemented bookmarks handling in XMLRenderer and AreaTreeParser. What puzzled me is that the bookmark tree wound up in the XML output as the last child of the last PageSequence, instead of after the last PageSequence. I don't understand how this can happen, OK, found it. And it's easily fixed. Regards, Paul Vinkenoog
DO NOT REPLY [Bug 41999] New: - Unassigned code points cause ArrayIndexOutOfBoundsException in LineBreakUtils
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41999. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41999 Summary: Unassigned code points cause ArrayIndexOutOfBoundsException in LineBreakUtils Product: Fop Version: all Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Documents that contain proposed new code points to unicode, such as those listed at http://www.unicode.org/alloc/Pipeline.html have a LineBreakProperty of zero as returned by LineBreakUtils.getLineBreakProperty(c). This then causes an index out of bounds exception in LineBreakUtils.getLineBreakPairProperty() when built from trunk. One solution might be to use LineBreakUtils.LINE_BREAK_PROPERTY_XX instead of zero for unassigned code points. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 41999] - Unassigned code points cause ArrayIndexOutOfBoundsException in LineBreakUtils
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41999. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41999 --- Additional Comments From [EMAIL PROTECTED] 2007-03-30 11:54 --- Created an attachment (id=19851) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19851action=view) unassigned-linebreak-property.patch a patch that uses LineBreakUtils.LINE_BREAK_PROPERTY_XX when the line break property class is zero to avoid the index out of bounds exception. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 41831] - [PATCH] Refactored configuration, font detection and caching, url resolution
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=41831.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41831
--- Additional Comments From [EMAIL PROTECTED] 2007-03-30 16:42 ---
I tried out this patch on Ubuntu Linux and found that I needed a few changes to
get it to work properly. Since this hasn't been checked in, I'm not sure what to
send a patch against, so I'll just describe them for now.
org.apache.fop.fonts.autodetect.UnixFontDirFinder
It is probably worth adding the .fonts directory in a user's home directory:
e.g.
UNIX_FONT_PATHS = {
System.getProperty(user.home) + /.fonts,
org.apache.fop.fonts.autodetect.FontFileFinder.find should have the recursive
argument set to true when called from
org.apache.fop.fonts.autodetect.NativeFontFileFinder.find, because the fonts are
found several layers deep under /usr/share/fonts.
org.apache.fop.fonts.autodetect.FontInfoFinder
If you use
embedUrl = fontFile.toURI().toURL().toExternalForm();
then it seems to do escaping of spaces, otherwise font filenames containing
spaces cause problems.
It is probably worth handling UnsupportedOperationException within the
org.apache.fop.fonts.autodetect.FontInfoFinder.find() method to prevent one bad
font breaking everything. I find OpenType fonts with CFF data are not
supported, yet errors thrown by org.apache.fop.fonts.truetype.TTFFontLoader
break the caching otherwise.
I'm not convinced that the cache is working properly for failed fonts, because I
always seem to get log messages about them, not just on the first run. However,
I haven't had time to investigate that properly.
cheers,
Keith
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
