Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Does this build system require us to deploy snapshots of xmlgraphics-commons and batik to the maven repository, whenever we use snapshot versions in our lib directory? We do routinely for xgc, and we may need to do so for batik if the headless problem is fixed (see https://issues.apache.org/bugzilla/show_bug.cgi?id=42408#c13). Simon On Sat, Sep 04, 2010 at 06:42:56AM -0400, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=49881 --- Comment #1 from Glenn Adams gl...@skynav.com 2010-09-04 06:42:53 EDT --- Created an attachment (id=25986) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25986) Patch to add maven build support. This patch has been verified against repository version 992575. -- Simon Pepping home page: http://www.leverkruid.eu
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
If I understand you correctly, the answer is no. The file maven/pom.xml in the patch explicitly references revision 1.7 of the batik artifacts. So any use of upward revisions of those artifacts would require updating the pom.xml file to reflect use of a newer revision. At present, I worked around the headless problem (testWMF) by specifying java.awt.headless as false in the pom.xml configuration for those test suites that invoke testWMF. Of course, that also means that the this patch will fail those tests when invoked on a truly headless platform. Does that answer your query? Or are you asking if I can adjust the configuration to make automatic use of snapshot updates? Regards, Glenn On Wed, Sep 8, 2010 at 3:47 PM, Simon Pepping spepp...@leverkruid.euwrote: Does this build system require us to deploy snapshots of xmlgraphics-commons and batik to the maven repository, whenever we use snapshot versions in our lib directory? We do routinely for xgc, and we may need to do so for batik if the headless problem is fixed (see https://issues.apache.org/bugzilla/show_bug.cgi?id=42408#c13). Simon On Sat, Sep 04, 2010 at 06:42:56AM -0400, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=49881 --- Comment #1 from Glenn Adams gl...@skynav.com 2010-09-04 06:42:53 EDT --- Created an attachment (id=25986) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25986) Patch to add maven build support. This patch has been verified against repository version 992575. -- Simon Pepping home page: http://www.leverkruid.eu
DO NOT REPLY [Bug 49893] [PATCH]AFP image handling configuration
https://issues.apache.org/bugzilla/show_bug.cgi?id=49893 Peter Hancock peter.hanc...@gmail.com changed: What|Removed |Added Summary|AFP image handling |[PATCH]AFP image handling |configuration |configuration -- 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: base 14 font kerning
Hi, On 07/09/10 10:00, Chris Bowditch wrote: Glenn Adams wrote: Hi Glenn/Jeremias, I've already implemented in my complex scripts work, so it will make it into trunk in due time. However, I think I'll leave the default setting as it is for the time being. Users can explicitly enable it via their config. We can take up the issue of whether to change the default at a future time. I do not like the idea of changing the default value of Kerning from off to on. The reason being that users who decide to upgrade their FOP version will suddenly find the appearance of their documents changing. Better to let users who are unsatisfied with the default inter character spacing to go and enable kerning than force users to regression test every document to make sure the changes to appearance is acceptable. I disagree. New users don’t care whether kerning was enabled in previous versions or not. They just want their documents to look good and don’t want to be told about some obscure configuration option. In fact, they may not even know what kerning is and they don’t want to be bothered with that. Kerning is something that font designers spend time to define in order for their fonts to look good, and not handling kerning is a bug. Kerning should be enabled by default. For users who are upgrading their version of FOP, a warning in the release notes should be enough. They /will/ have to regression test their documents anyway. Vincent Thanks, Chris G. On Mon, Sep 6, 2010 at 10:07 PM, Jeremias Maerki d...@jeremias-maerki.ch mailto:d...@jeremias-maerki.ch wrote: I think that is for historical reasons. When this was implemented (I think it was me) I guess we didn't want to change the layout behaviour for existing users. For a long time, kerning for base 14 fonts was not supported. http://svn.apache.org/viewvc?view=revisionrevision=389086 http://svn.apache.org/viewvc?view=revisionrevision=389086 You're right: this setting doesn't seem to be tied into the FontManagerConfigurator. It would be great if you added that. That said, I'm not sure if enabling that would be so bad. I guess I'm not opposed to it. On 06.09.2010 07:58:41 Glenn Adams wrote: Is there a reason that kerning of the base 14 fonts is disabled by default? Furthermore, except by programmatic means, there does not seem to be a way to enable it except by using FontManager.setBase14KerningEnabled() or the deprecated method FopFactory.setBase14KerningEnabled(). This technique is used to enable it during testing in one test case: layoutengine/standard-testcases/kerning_1_on.xml, by means of special code in org.apache.fop.layoutengine.TestEnvironment. However, there appears no way for a user to enable it via non-programmitc means. To support this (which I need in testing the new generalized position adjustments for text drawing), I'm adding a base14-kerning element to be placed in the top-level fop element in the FOP configuration file, e.g., fop ... base14-kerningtrue/base14-kerning ... /fop The rationale for making this a child of the top-level fop element is that the enable/disable state is presently maintained in the singleton FontManager instance, which is configured (in FontManagerConfigurator) from other top-level children of the fop element. For consistency, it my be better to enable base14 kerning by default, then allow a user to disable it using the above mechanism. However, I have not made this latter change (yet). Comments? G. Jeremias Maerki
Re: TODO tag [was: Re: svn commit: r990148 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: area/ fo/ fo/flow/ fo/flow/table/ fo/pagination/ fo/properties/ hyphenation/ layoutmgr/ layoutmgr/inline
+1! On 08.09.2010 13:02:29 Vincent Hennebert wrote: Ok, let me summarise this: • a @[asf.]todo tag marginally improves the formatting of a javadoc comment • nobody really likes the idea of using a namespaced version of todo (@asf.todo) • it is possible to tweak Checkstyle and the javadoc command to enable the use of @todo That said: • todo statements generally have little to do (sic) in a javadoc comment anyway • TODO keywords are easily indexable by modern IDEs Jeremias recommends the Felix way: using //TODO comments below the javadoc. I’m also strongly in favour of this convention. OTOH, if I’m correct nobody strongly feels that @todo tags are necessary. So I think we have a consensus: • from now on we stop using @todo in favour of the Felix convention; • we will progressively remove TODO statements from javadoc comments and move them below in their own Java // comments • I remove the definition of the custom tag from build.xml Let me know if I missed anything. Thanks, Vincent snip/ Jeremias Maerki
RE: TODO tag [was: Re: svn commit: r990148 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: area/ fo/ fo/flow/ fo/flow/table/ fo/pagination/ fo/properties/ hyphenation/ layoutmgr/ layoutmgr/inline
I agree. TODO should be something for the developer of the objects. Javadoc should be something for the developer of something which implements those objects. They don't really belong together. I'd keep separate documentation if you want to let the implementing programmer know what the developing programmer is planning to do next. I think taking the @ off the TODO makes sense. -Original Message- From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch] Sent: Wednesday, September 08, 2010 8:19 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: TODO tag [was: Re: svn commit: r990148 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: area/ fo/ fo/flow/ fo/flow/table/ fo/pagination/ fo/properties/ hyphenation/ layoutmgr/ layoutmgr/inline/ layoutmgr/table/] +1! On 08.09.2010 13:02:29 Vincent Hennebert wrote: Ok, let me summarise this: * a @[asf.]todo tag marginally improves the formatting of a javadoc comment * nobody really likes the idea of using a namespaced version of todo (@asf.todo) * it is possible to tweak Checkstyle and the javadoc command to enable the use of @todo That said: * todo statements generally have little to do (sic) in a javadoc comment anyway * TODO keywords are easily indexable by modern IDEs Jeremias recommends the Felix way: using //TODO comments below the javadoc. I'm also strongly in favour of this convention. OTOH, if I'm correct nobody strongly feels that @todo tags are necessary. So I think we have a consensus: * from now on we stop using @todo in favour of the Felix convention; * we will progressively remove TODO statements from javadoc comments and move them below in their own Java // comments * I remove the definition of the custom tag from build.xml Let me know if I missed anything. Thanks, Vincent snip/ Jeremias Maerki
Re: base 14 font kerning
Hi, I’m just remembering this bug, that may affect you: https://issues.apache.org/bugzilla/show_bug.cgi?id=48766 Vincent On 06/09/10 06:58, Glenn Adams wrote: Is there a reason that kerning of the base 14 fonts is disabled by default? Furthermore, except by programmatic means, there does not seem to be a way to enable it except by using FontManager.setBase14KerningEnabled() or the deprecated method FopFactory.setBase14KerningEnabled(). This technique is used to enable it during testing in one test case: layoutengine/standard-testcases/kerning_1_on.xml, by means of special code in org.apache.fop.layoutengine.TestEnvironment. However, there appears no way for a user to enable it via non-programmitc means. To support this (which I need in testing the new generalized position adjustments for text drawing), I'm adding a base14-kerning element to be placed in the top-level fop element in the FOP configuration file, e.g., fop ... base14-kerningtrue/base14-kerning ... /fop The rationale for making this a child of the top-level fop element is that the enable/disable state is presently maintained in the singleton FontManager instance, which is configured (in FontManagerConfigurator) from other top-level children of the fop element. For consistency, it my be better to enable base14 kerning by default, then allow a user to disable it using the above mechanism. However, I have not made this latter change (yet). Comments? G.
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
I think I mean something different. When XGC adds something new and FOP uses that, a new XGC jar file must be used by builds. We do that by having a new jar file in /lib, typically called xmlgraphics-commons-1.5-svn.jar (which may be updated a few times during development of the next release). How would that be handled by the maven build? Would it require the deployment of a snapshot to Maven central? And would the version number in the pom file be updated? Simon On Wed, Sep 08, 2010 at 05:13:07PM +0800, Glenn Adams wrote: If I understand you correctly, the answer is no. The file maven/pom.xml in the patch explicitly references revision 1.7 of the batik artifacts. So any use of upward revisions of those artifacts would require updating the pom.xml file to reflect use of a newer revision. At present, I worked around the headless problem (testWMF) by specifying java.awt.headless as false in the pom.xml configuration for those test suites that invoke testWMF. Of course, that also means that the this patch will fail those tests when invoked on a truly headless platform. Does that answer your query? Or are you asking if I can adjust the configuration to make automatic use of snapshot updates? Regards, Glenn On Wed, Sep 8, 2010 at 3:47 PM, Simon Pepping spepp...@leverkruid.euwrote: Does this build system require us to deploy snapshots of xmlgraphics-commons and batik to the maven repository, whenever we use snapshot versions in our lib directory? We do routinely for xgc, and we may need to do so for batik if the headless problem is fixed (see https://issues.apache.org/bugzilla/show_bug.cgi?id=42408#c13). -- Simon Pepping home page: http://www.leverkruid.eu
Re: base 14 font kerning
I just took a look, and that bug seems to be a Type1 AFM/PS issue, different from the enabling/disabling of base14 font kerning. However, in the comment thread of it, you do make a point that is worth repeating for those who aren't aware of it, namely, kerning occurs between glyphs, and not characters. The problem is that many readers do not distinguish between a character and a glyph. I wrote a series of articles on this subject in 1991, a good deal of which made it into ISO/IEC TR 15285 *Information technology - An operation model for characters and glyphs*, which I co-authored. Some of this information can also be found in http://www.w3.org/TR/charmod/, e.g., at Units of visual renderinghttp://www.w3.org/TR/charmod/#sec-VisualRenderingUnits . In the context of FOP, it is important to keep in mind the distinction and to translate when necessary. For example, Font.getCharWidth() returns the x advancement of the glyph associated with the single Java char parameter, which encodes a single UTF-16 code element, which is interpreted as a Unicode scalar value (in the BMP), is then mapped through the CMAP (or equivalent) to a glyph identifier (glyph code) associated with an x advancement. One might have instead created three methods: getXAdvanceUsingBMPCode(char code) // 0 = code 65536; code != surrogate getXAdvanceUsingUnicodeScalar(int code)// 0 = code 1114112; code != surrogate getXAdvanceUsingGlyphCode(int code)// 0 = code font.getGlyphCount() At present, the method Font.getCharWidth(char) is equivalent to the first of the above, getXAdvanceUsingBMPCode, though it does not check for invalid use of surrogates. Also, as I've pointed out in the past, there are more than a few places in FOP where a Unicode Scalar should be passed as an int value instead of using the Java char type, which technically denotes a UTF-16 encoding element. G. On Wed, Sep 8, 2010 at 9:52 PM, Vincent Hennebert vhenneb...@gmail.comwrote: Hi, I’m just remembering this bug, that may affect you: https://issues.apache.org/bugzilla/show_bug.cgi?id=48766 Vincent On 06/09/10 06:58, Glenn Adams wrote: Is there a reason that kerning of the base 14 fonts is disabled by default? Furthermore, except by programmatic means, there does not seem to be a way to enable it except by using FontManager.setBase14KerningEnabled() or the deprecated method FopFactory.setBase14KerningEnabled(). This technique is used to enable it during testing in one test case: layoutengine/standard-testcases/kerning_1_on.xml, by means of special code in org.apache.fop.layoutengine.TestEnvironment. However, there appears no way for a user to enable it via non-programmitc means. To support this (which I need in testing the new generalized position adjustments for text drawing), I'm adding a base14-kerning element to be placed in the top-level fop element in the FOP configuration file, e.g., fop ... base14-kerningtrue/base14-kerning ... /fop The rationale for making this a child of the top-level fop element is that the enable/disable state is presently maintained in the singleton FontManager instance, which is configured (in FontManagerConfigurator) from other top-level children of the fop element. For consistency, it my be better to enable base14 kerning by default, then allow a user to disable it using the above mechanism. However, I have not made this latter change (yet). Comments? G.
Re: TODO tag
Of the three options: 1. @todo 2. @asf.todo 3. //TODO I prefer @todo, even if it means having a javadoc warning, but perhaps that warning can be suppressed. G. On Thu, Sep 9, 2010 at 1:24 AM, Simon Pepping spepp...@leverkruid.euwrote: //TODO is unstructured. @todo fits into an existing syntax, viz. that of javadoc tags. Output in javadocs can be suppressed by '-tag todo:X'. My preference is therefore a javadoc tag, @todo. But I am not going to make a case of this. +0. Simon On Wed, Sep 08, 2010 at 12:02:29PM +0100, Vincent Hennebert wrote: Ok, let me summarise this: ??? a @[asf.]todo tag marginally improves the formatting of a javadoc comment ??? nobody really likes the idea of using a namespaced version of todo (@asf.todo) ??? it is possible to tweak Checkstyle and the javadoc command to enable the use of @todo That said: ??? todo statements generally have little to do (sic) in a javadoc comment anyway ??? TODO keywords are easily indexable by modern IDEs Jeremias recommends the Felix way: using //TODO comments below the javadoc. I???m also strongly in favour of this convention. OTOH, if I???m correct nobody strongly feels that @todo tags are necessary. So I think we have a consensus: ??? from now on we stop using @todo in favour of the Felix convention; ??? we will progressively remove TODO statements from javadoc comments and move them below in their own Java // comments ??? I remove the definition of the custom tag from build.xml Let me know if I missed anything. -- Simon Pepping home page: http://www.leverkruid.eu
Re: svn commit: r995176 - in /xmlgraphics/fop/branches/Temp_ComplexScripts: ./ src/java/org/apache/fop/afp/ src/java/org/apache/fop/afp/modca/ src/java/org/apache/fop/area/ src/java/org/apache/fop/dat
Simon, Thanks for keeping the branch up to date! It is a big help. FYI, I'm expecting to post a new follow-on patch for the branch (perhaps over the next week) in order to add support for non-spacing marks (and generalized position adjustments - namely the OpenType GPOS table). G. On Thu, Sep 9, 2010 at 2:10 AM, spepp...@apache.org wrote: Author: spepping Date: Wed Sep 8 18:10:47 2010 New Revision: 995176 URL: http://svn.apache.org/viewvc?rev=995176view=rev Log: Merged changes from trunk up to revision 995168
Re: DO NOT REPLY [Bug 49881] [PATCH] add maven build support
Ah, ok. Off hand, I see three ways to handle this, one of which you mention: (1) deploy xmlgraphics-commons-1.5-SNAPSHOT.jar to a public maven repo and update the maven/pom.xml to refer to this version; (2) install xmlgraphics-commons-1.5-SNAPSHOT.jar in your local maven repo and update the maven/pom.xml to refer to this version; (3) modify maven/pom.xml to exclude the dependency from the class path, but then add a reference to the local XGC jar to the classpath (for compiles and tests); I would probably choose option (2), since that puts the onus on the user of the maven build config rather than on the updater of XGC (who may not be familiar with deploying a snapshot). The change to maven/pom.xml to use the snapshot version could be committed, and not just a local copy; instructions to set up the local repo copy of the snapshot would then be added to the maven readme file I created. G. On Thu, Sep 9, 2010 at 1:30 AM, Simon Pepping spepp...@leverkruid.euwrote: I think I mean something different. When XGC adds something new and FOP uses that, a new XGC jar file must be used by builds. We do that by having a new jar file in /lib, typically called xmlgraphics-commons-1.5-svn.jar (which may be updated a few times during development of the next release). How would that be handled by the maven build? Would it require the deployment of a snapshot to Maven central? And would the version number in the pom file be updated? Simon On Wed, Sep 08, 2010 at 05:13:07PM +0800, Glenn Adams wrote: If I understand you correctly, the answer is no. The file maven/pom.xml in the patch explicitly references revision 1.7 of the batik artifacts. So any use of upward revisions of those artifacts would require updating the pom.xml file to reflect use of a newer revision. At present, I worked around the headless problem (testWMF) by specifying java.awt.headless as false in the pom.xml configuration for those test suites that invoke testWMF. Of course, that also means that the this patch will fail those tests when invoked on a truly headless platform. Does that answer your query? Or are you asking if I can adjust the configuration to make automatic use of snapshot updates? Regards, Glenn On Wed, Sep 8, 2010 at 3:47 PM, Simon Pepping spepp...@leverkruid.eu wrote: Does this build system require us to deploy snapshots of xmlgraphics-commons and batik to the maven repository, whenever we use snapshot versions in our lib directory? We do routinely for xgc, and we may need to do so for batik if the headless problem is fixed (see https://issues.apache.org/bugzilla/show_bug.cgi?id=42408#c13). -- Simon Pepping home page: http://www.leverkruid.eu
