Definition of Public API was (Re: svn commit: r1234877 - in /xmlgraphics/fop/trunk: examples/embedding/java/embedding/ examples/embedding/java/embedding/atxml/ src/java/org/apache/fop/cli/ src/java/or
On 25/01/2012 14:59, mehdi houshmand wrote: Hi Mehdi, I've spent some time looking through the examples and the documentation above and I think the classes listed below are all the classes necessary for most the use-cases and thus should be considered the public API. org.apache.fop.apps.* org.apache.fop.fo.FOEventHandler org.apache.fop.fonts.FontManager org.apache.fop.events.EventListener org.apache.fop.events.Event org.apache.fop.events.model.EventSeverity org.apache.fop.render.RendererFactory org.apache.fop.render.intermediate.IFDocumentHandler org.apache.fop.render.intermediate.IFParser org.apache.fop.render.intermediate.IFUtil org.apache.fop.render.intermediate.IFSerializer org.apache.fop.render.intermediate.IFContext This would mean deprecating o.a.f.apps.FOUserAgent.setRendererOverride(...) since (if I'm not mistaken) this is legacy code to bind a MIME type to IF output. Obviously I would also give instructions to use the IFDocumentHandler implementation. Also, while we're at it, the IFDocumentHandler method isn't described on the link above, so I'll try and put some information there as well. Thanks for preparing the list of classes that form the public API. I have chcked the code that we use to embed FOP and it's all present in the above list. A shame that its necessary to use classes from render.intermediate in order to go FO-IF-PDF. In an ideal world those classes should be in a top level intermediate package or a sub package of apps, but that won't be easy to change now! +1 to adding the above list to the website so we now have a clear definition of what is part of the API and what is not. The changes you propose to the move foUserAgent to the Renderer constructors do not affect any of the above API classes so +1 to commit those too. Thanks, Chris I plan to put this information on the website, so please feel free to discuss if you have any questions and/or wish to make amendments. Mehdi On 24 January 2012 19:36, Glenn Adamsgl...@skynav.com wrote: On Tue, Jan 24, 2012 at 10:08 AM, Vincent Hennebertvhenneb...@gmail.com wrote: I would consider to be part of the public API the code that is present on the following page: http://xmlgraphics.apache.org/fop/trunk/embedding.html I agree. We should distinguish between APIs documented as being explicitly part of the embedding APIs and other public interfaces/members not documented as such. Also, it is probably good to review, at least during every release, whether the embedding API documentation is correct and complete.
Static main methods
Hi, Another proposal for public consideration: There seem to be an awful lot of static main methods around the fonts and hyphenation packages, I was wondering if anyone had any objections to moving all these methods into classes under a single package i.e. org.apache.fop.cli.utils. This would involve more than merely copy/pasting the main method itself, but also some of the ancillary methods that are only used by static main methods. Obviously, this would include updating the documentation to reflect the migration. The reason I'm making this proposition is that I'm trying to unify the URI resolution and file access within FOP, we currently use 5 URI resolvers, without including what XMLGraphics and Batik do, (FOURIResolver, FontResolver, HyphenationTreeResolver, DataURIResolver, DTDEntityResolver) which I think we can all agree is a little excessive. In so doing, I keep bumping up against these static main methods or functions that are only called by them, and it seems to me that while I'm at it, I might as well do some clean up. Anyways your collective thoughts would be appreciated on the matter, Mehdi
checkstyle errors, deprecation
I notice 4 checkstyle errors have creeped into recent trunk commits. Also, there is a deprecated usage in one of the junit tests (run junit-compile target) that has been around for a while that should be fixed: % ant junit-compile ... [javac] /users/glenn/Work/fop/test/java/org/apache/fop/fonts/truetype/TTFFontLoaderTestCase.java:42: warning: [deprecation] toURL() in java.io.File has been deprecated [javac] String absoluteFilePath = file.toURL().toExternalForm(); Maybe a committer could fix these.
Re: Static main methods
Am 27.01.2012 16:35, schrieb mehdi houshmand: There seem to be an awful lot of static main methods around the fonts and hyphenation packages, I was wondering if anyone had any objections to moving all these methods into classes under a single package i.e. AFAIR all of these are there to facilitate development and testing, the font metrics and the hyphenation class generator being the only exceptions. They are not meant for the average user. Most if not all could probably be deleted, or a least moved into the test tree. I'm not sure what to do with the metrics generator, as the metrics file is deprecated anyway. The hyphenation class generator is already a class for itself (which ist overly complicated and could probably share more code with the ant task). Another possibility would be to get rid of explicitely building serialized hyphenation classes and use a caching mechanism for processed hyphenation patterns, somewhat similar to fonts. (FOURIResolver, FontResolver, HyphenationTreeResolver, DataURIResolver, DTDEntityResolver) which I think we can all agree is a little excessive. Unfortunately, there are at least two different APIs involved, and there are still reasons users should be able to set different resolvers for different purposes. Using an underlying unified API makes sense, however I remember unifying DTDEntityResolver and the other Resolvers run into difficulties (maybe related to XML catalogs). J.Pietschmann
DO NOT REPLY [Bug 49687] [PATCH] Complex Script Support
https://issues.apache.org/bugzilla/show_bug.cgi?id=49687
--- Comment #48 from Glenn Adams gl...@skynav.com 2012-01-27 20:27:02 UTC ---
Created attachment 28220
-- https://issues.apache.org/bugzilla/attachment.cgi?id=28220
Patch to revision 1236835 of trunk.
This patch is to be applied to revision 1236835 of trunk as follows:
cd ${FOP}/trunk
svn status # check and remove any unexpected changes prior to patchingsvn
update -r 1236835 --force
svn revert -R .
svn status # check and remove any unexpected changes prior to patching
gzcat ${DOWNLOADS}/fop-complexscripts-patch-2.diff.gz | patch -p1
ant clean
ant codegen-unicode-bidi
ant resgen-complexscripts
ant clean
svn add src/codegen/unicode/java/org/apache/fop/complexscripts
svn add src/java/org/apache/fop/complexscripts
svn add src/java/org/apache/fop/traits/Direction.java
svn add src/java/org/apache/fop/traits/WritingMode.java
svn add src/java/org/apache/fop/traits/WritingModeTraits.java
svn add src/java/org/apache/fop/traits/WritingModeTraitsGetter.java
svn add src/java/org/apache/fop/traits/WritingModeTraitsSetter.java
svn add test/java/org/apache/fop/complexscripts
svn add
test/layoutengine/standard-testcases/basic-link_background-image_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/basic-link_external-destination_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/basic-link_external-destination_writing-mode_rl_2.xml
svn add
test/layoutengine/standard-testcases/basic-link_for_toc_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/basic-link_height_baseline-shift_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/basic-link_height_inline-child_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/basic-link_height_multi-child_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/basic-link_height_multi-line_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/basic-link_height_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/basic-link_internal-desination-next-page.xml
svn add
test/layoutengine/standard-testcases/basic-link_internal-desination-next-page_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/basic-link_internal-desination-same-page-after.xml
svn add
test/layoutengine/standard-testcases/basic-link_internal-desination-same-page-after_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/basic-link_internal-desination-same-page-before.xml
svn add
test/layoutengine/standard-testcases/basic-link_internal-desination-same-page-before_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/block-container_start-indent_writing-mode_rl.xml
svn add test/layoutengine/standard-testcases/block_text-align_4.xml
svn add test/layoutengine/standard-testcases/block_text-align_5.xml
svn add test/layoutengine/standard-testcases/character_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/inline_background-color_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/instream-foreign-object_basic_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/instream-foreign-object_border_padding_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/instream-foreign-object_display-align_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/leader-alignment_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/leader_leader-pattern_dots_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/leader_leader-pattern_rule_writing-system_rl.xml
svn add
test/layoutengine/standard-testcases/leader_leader-pattern_space_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/leader_leader-pattern_use-content_writing-mode_rl.xml
svn add test/layoutengine/standard-testcases/list-block_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/page-number-citation_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/region-body_column-count_1_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/region-body_column-count_2_writing-mode_rl.xml
svn add
test/layoutengine/standard-testcases/table-column_column-progression-lr.xml
svn add
test/layoutengine/standard-testcases/table-column_column-progression-rl.xml
svn add test/resources/complexscripts
svn propdel svn:mime-type test/resources/complexscripts/arab/data/arab-001.txt
svn commit ...
This patch replaces (obsoletes) all previous patches on this bug and includes
the following:
Bug Fixes
* fo:block-container start-indent in bidi context
(http://skynav.trac.cvsdude.com/fop/ticket/64)
* fo:static-content fails to process bidirectional levels
(http://skynav.trac.cvsdude.com/fop/ticket/70)
* ignores standard kerning when font has GSUB but not GPOS
(http://skynav.trac.cvsdude.com/fop/ticket/71)
* fo:leader not fully supported in bidi context
(http://skynav.trac.cvsdude.com/fop/ticket/74)
New Features
* preliminary support for gujarati script
DO NOT REPLY [Bug 49687] [PATCH] Complex Script Support
https://issues.apache.org/bugzilla/show_bug.cgi?id=49687 Glenn Adams gl...@skynav.com changed: What|Removed |Added Attachment #25912|0 |1 is obsolete|| -- 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 49687] [PATCH] Complex Script Support
https://issues.apache.org/bugzilla/show_bug.cgi?id=49687 Glenn Adams gl...@skynav.com changed: What|Removed |Added Attachment #26104|0 |1 is obsolete|| -- 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 49687] [PATCH] Complex Script Support
https://issues.apache.org/bugzilla/show_bug.cgi?id=49687 Glenn Adams gl...@skynav.com changed: What|Removed |Added Attachment #26721|0 |1 is obsolete|| -- 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 49687] [PATCH] Complex Script Support
https://issues.apache.org/bugzilla/show_bug.cgi?id=49687 Glenn Adams gl...@skynav.com changed: What|Removed |Added Attachment #27161|0 |1 is obsolete|| -- 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 49687] [PATCH] Complex Script Support
https://issues.apache.org/bugzilla/show_bug.cgi?id=49687 Glenn Adams gl...@skynav.com changed: What|Removed |Added Attachment #27784|0 |1 is obsolete|| -- 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: Definition of Public API was (Re: svn commit: r1234877 - in /xmlgraphics/fop/trunk: examples/embedding/java/embedding/ examples/embedding/java/embedding/atxml/ src/java/org/apache/fop/cli/ src/jav
I suggest to add 2 more classes to what is considered a public API. 1. org.apache.fop.render.intermediate.IFException This is obvious. Let's add it even though nobody will probably make there any backwards incompatible change. 2. org.apache.fop.render.intermediate.util.IFConcatenator It makes no sense including the IFSerializer class and leaving out the class that reads FOP IF files and creates the final output format. This is used at least in embedding.intermediate.ExampleConcat.java Alexios Giotis On Jan 27, 2012, at 1:23 PM, Chris Bowditch wrote: On 25/01/2012 14:59, mehdi houshmand wrote: Hi Mehdi, I've spent some time looking through the examples and the documentation above and I think the classes listed below are all the classes necessary for most the use-cases and thus should be considered the public API. org.apache.fop.apps.* org.apache.fop.fo.FOEventHandler org.apache.fop.fonts.FontManager org.apache.fop.events.EventListener org.apache.fop.events.Event org.apache.fop.events.model.EventSeverity org.apache.fop.render.RendererFactory org.apache.fop.render.intermediate.IFDocumentHandler org.apache.fop.render.intermediate.IFParser org.apache.fop.render.intermediate.IFUtil org.apache.fop.render.intermediate.IFSerializer org.apache.fop.render.intermediate.IFContext This would mean deprecating o.a.f.apps.FOUserAgent.setRendererOverride(...) since (if I'm not mistaken) this is legacy code to bind a MIME type to IF output. Obviously I would also give instructions to use the IFDocumentHandler implementation. Also, while we're at it, the IFDocumentHandler method isn't described on the link above, so I'll try and put some information there as well. Thanks for preparing the list of classes that form the public API. I have chcked the code that we use to embed FOP and it's all present in the above list. A shame that its necessary to use classes from render.intermediate in order to go FO-IF-PDF. In an ideal world those classes should be in a top level intermediate package or a sub package of apps, but that won't be easy to change now! +1 to adding the above list to the website so we now have a clear definition of what is part of the API and what is not. The changes you propose to the move foUserAgent to the Renderer constructors do not affect any of the above API classes so +1 to commit those too. Thanks, Chris I plan to put this information on the website, so please feel free to discuss if you have any questions and/or wish to make amendments. Mehdi On 24 January 2012 19:36, Glenn Adamsgl...@skynav.com wrote: On Tue, Jan 24, 2012 at 10:08 AM, Vincent Hennebertvhenneb...@gmail.com wrote: I would consider to be part of the public API the code that is present on the following page: http://xmlgraphics.apache.org/fop/trunk/embedding.html I agree. We should distinguish between APIs documented as being explicitly part of the embedding APIs and other public interfaces/members not documented as such. Also, it is probably good to review, at least during every release, whether the embedding API documentation is correct and complete.
Complex Scripts Patch
I have posted a new patch [1] against trunk (revision 1236835). [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=49687#c48 This patch is a cumulative patch, that, if applied to the specified trunk revision, brings up to date the trunk to my current FOP Complex Scripts repository state. The main changes in this patch include bug fixes, new features, and refactoring and cleanup, about which see [1] for additional details. Of particular relevance is that this patch attempts to address a number of comments previously made by reviewers, specifically: - need to reduce the size of large class files - this was accomplished by promoting nested classes to non-nested classes and by further subdividing functionality into distinct classes, e.g., the parsing of advanced typographic tables was moved from TTFFile into a new class OTFAdvancedTypographicTableReader; - need to reduce dependency of bidi functionality on specific FONode and Area class types - this was accomplished by better using the class hierarchy of FONode and Area classes (as opposed to excessive use of instanceof), see, e.g., FONode.collectDelimitedTextRanges(...) and InlineArea.collectInlineRuns(...); - need to better segregate complex script functionality - with the exception of FONode and Area specific semantics, this was accomplished by moving most new complex script functionality into a new package hierarchy org.apache.fop.complexscripts I believe this patch is ready to be merged into trunk. I am willing to help facilitate this process however I can. Regards, Glenn
Re: Definition of Public API was (Re: svn commit: r1234877 - in /xmlgraphics/fop/trunk: examples/embedding/java/embedding/ examples/embedding/java/embedding/atxml/ src/java/org/apache/fop/cli/ src/jav
Well spotted Alexios, I will add both and double check there is adequate documentation on usage. Mehdi On 27 January 2012 20:50, Alexios Giotis alex.gio...@gmail.com wrote: I suggest to add 2 more classes to what is considered a public API. 1. org.apache.fop.render.intermediate.IFException This is obvious. Let's add it even though nobody will probably make there any backwards incompatible change. 2. org.apache.fop.render.intermediate.util.IFConcatenator It makes no sense including the IFSerializer class and leaving out the class that reads FOP IF files and creates the final output format. This is used at least in embedding.intermediate.ExampleConcat.java Alexios Giotis On Jan 27, 2012, at 1:23 PM, Chris Bowditch wrote: On 25/01/2012 14:59, mehdi houshmand wrote: Hi Mehdi, I've spent some time looking through the examples and the documentation above and I think the classes listed below are all the classes necessary for most the use-cases and thus should be considered the public API. org.apache.fop.apps.* org.apache.fop.fo.FOEventHandler org.apache.fop.fonts.FontManager org.apache.fop.events.EventListener org.apache.fop.events.Event org.apache.fop.events.model.EventSeverity org.apache.fop.render.RendererFactory org.apache.fop.render.intermediate.IFDocumentHandler org.apache.fop.render.intermediate.IFParser org.apache.fop.render.intermediate.IFUtil org.apache.fop.render.intermediate.IFSerializer org.apache.fop.render.intermediate.IFContext This would mean deprecating o.a.f.apps.FOUserAgent.setRendererOverride(...) since (if I'm not mistaken) this is legacy code to bind a MIME type to IF output. Obviously I would also give instructions to use the IFDocumentHandler implementation. Also, while we're at it, the IFDocumentHandler method isn't described on the link above, so I'll try and put some information there as well. Thanks for preparing the list of classes that form the public API. I have chcked the code that we use to embed FOP and it's all present in the above list. A shame that its necessary to use classes from render.intermediate in order to go FO-IF-PDF. In an ideal world those classes should be in a top level intermediate package or a sub package of apps, but that won't be easy to change now! +1 to adding the above list to the website so we now have a clear definition of what is part of the API and what is not. The changes you propose to the move foUserAgent to the Renderer constructors do not affect any of the above API classes so +1 to commit those too. Thanks, Chris I plan to put this information on the website, so please feel free to discuss if you have any questions and/or wish to make amendments. Mehdi On 24 January 2012 19:36, Glenn Adamsgl...@skynav.com wrote: On Tue, Jan 24, 2012 at 10:08 AM, Vincent Hennebertvhenneb...@gmail.com wrote: I would consider to be part of the public API the code that is present on the following page: http://xmlgraphics.apache.org/fop/trunk/embedding.html I agree. We should distinguish between APIs documented as being explicitly part of the embedding APIs and other public interfaces/members not documented as such. Also, it is probably good to review, at least during every release, whether the embedding API documentation is correct and complete.
