Fw: Re: [css3-text] Hyphenation Resources
Hi fop devs. There is discussion on www-st...@w3.org about hypenation dictionary formats, and FOP was mentioned. Does someone have the knowledge to comment there? - Forwarded message from John Daggett jdagg...@mozilla.com - From: John Daggett jdagg...@mozilla.com Date: Mon, 31 Jan 2011 23:36:59 -0800 (PST) To: www-style list www-st...@w3.org Cc: l...@w3.org, jfkth...@gmail.com Subject: Re: [css3-text] Hyphenation Resources Archived-At: http://www.w3.org/mid/1971349164.157469.1296545819806.javamail.r...@cm-mail03.mozilla.org Looking at this a tiny bit more, it appears that the AH format is actually based on FOP: http://xmlgraphics.apache.org/fop/1.0/hyphenation.html I'm curious if folks working on XSL/FOP feel that the formats and algorithms used for automated hyphenation have been sufficiently flushed out enough to allow for a common format? Or would it be better to allow user agents room to innovate and then define something later? John Daggett cc'ing Liam Quinn - Original Message - From: John Daggett jdagg...@mozilla.com To: www-style list www-st...@w3.org Sent: Tuesday, February 1, 2011 4:15:08 PM Subject: [css3-text] Hyphenation Resources The current CSS3 Text spec defines a 'hyphenation-resource' @-rule: http://dev.w3.org/csswg/css3-text/#hyphenation-resource This was based on a similar property defined in CSS3 GCPM: http://dev.w3.org/csswg/css3-gcpm/#the-hyphenate-resource-property However, neither of these reference or define a syntax for the hyphenation resource. Effectively, these are UA-specific resources when defined this way. As such, I don't see any reason for supporting either the @-rule or the property in the current form; they're both effectively vendor-specific properties with *no* interoperability between user agents. I think the format should be defined/referenced explicitly or it should be removed from the spec and left to a vendor-specific property. For example, Antenna House uses this syntax: http://www.antennahouse.com/product/ahf50/hyp_dictionary.htm Would this be a suitable format to require? Or is there another publicly available format that would also suffice? Maybe something from TeX would work? What does Prince use? I think one argument will be that CSS doesn't specify formats for other types of resources such as images. But in the case of images there were already well-supported image types, so it wasn't really necessary to specify these to achieve some form of interoperability. The same is not true for hyphenation dictionaries. Regards, John Daggett - End forwarded message - -- Cameron McCormack ≝ http://mcc.id.au/
Re: [css3-text] Hyphenation Resources
Hi Cameron I'm not sure if it is feasible to have/create a standardized format. I guess it makes sense to stay as close to LaTex as possible. FOP just put the patterns into an XML format (using Unicode). It seems to work fine for us. Java-based CSS3 implementation could easily re-use FOP's hyphenation module. We rarely have inquiries on the user list concerning hyphenation. The larger issues is the mess of licenses for the various patterns which is why we've had to move the patterns outside to http://offo.sf.net because we can't fulfil the Apache Foundation's license policy. Tracking down individual authors of the original pattern files and getting permission to put them under the ALv2 turned out to be a tedious task. Not all authors can be contacted. So today, the users would essentially have to check for themselves if the license restrictions are fine for their particular use case. There was once a discussion about looking toward OpenOffice (probably rather LibreOffice today) for re-use of their hyphenation modules. But that hasn't happened probably due to effort that would need to be invested for the change. I haven't looked into that closely myself. But it could be another option for CSS3 implementations. That said, it would certainly be very very useful to have a good set of widely usable hyphenation patterns that have a clear, uniform and permissive license. The current situation is less than ideal for Apache FOP. HTH On 01.02.2011 09:04:21 Cameron McCormack wrote: Hi fop devs. There is discussion on www-st...@w3.org about hypenation dictionary formats, and FOP was mentioned. Does someone have the knowledge to comment there? - Forwarded message from John Daggett jdagg...@mozilla.com - From: John Daggett jdagg...@mozilla.com Date: Mon, 31 Jan 2011 23:36:59 -0800 (PST) To: www-style list www-st...@w3.org Cc: l...@w3.org, jfkth...@gmail.com Subject: Re: [css3-text] Hyphenation Resources Archived-At: http://www.w3.org/mid/1971349164.157469.1296545819806.javamail.r...@cm-mail03.mozilla.org Looking at this a tiny bit more, it appears that the AH format is actually based on FOP: http://xmlgraphics.apache.org/fop/1.0/hyphenation.html I'm curious if folks working on XSL/FOP feel that the formats and algorithms used for automated hyphenation have been sufficiently flushed out enough to allow for a common format? Or would it be better to allow user agents room to innovate and then define something later? John Daggett cc'ing Liam Quinn - Original Message - From: John Daggett jdagg...@mozilla.com To: www-style list www-st...@w3.org Sent: Tuesday, February 1, 2011 4:15:08 PM Subject: [css3-text] Hyphenation Resources The current CSS3 Text spec defines a 'hyphenation-resource' @-rule: http://dev.w3.org/csswg/css3-text/#hyphenation-resource This was based on a similar property defined in CSS3 GCPM: http://dev.w3.org/csswg/css3-gcpm/#the-hyphenate-resource-property However, neither of these reference or define a syntax for the hyphenation resource. Effectively, these are UA-specific resources when defined this way. As such, I don't see any reason for supporting either the @-rule or the property in the current form; they're both effectively vendor-specific properties with *no* interoperability between user agents. I think the format should be defined/referenced explicitly or it should be removed from the spec and left to a vendor-specific property. For example, Antenna House uses this syntax: http://www.antennahouse.com/product/ahf50/hyp_dictionary.htm Would this be a suitable format to require? Or is there another publicly available format that would also suffice? Maybe something from TeX would work? What does Prince use? I think one argument will be that CSS doesn't specify formats for other types of resources such as images. But in the case of images there were already well-supported image types, so it wasn't really necessary to specify these to achieve some form of interoperability. The same is not true for hyphenation dictionaries. Regards, John Daggett - End forwarded message - -- Cameron McCormack ? http://mcc.id.au/ Jeremias Maerki
Re: [VOTE] Merge FOP color branch into trunk
You are right. I got confused by various issues in my tools. The jar file was built by 'ant jar-main'. This target includes all cruft that is present in the build directory. The build files could do with an includes attribute in the jar task. Simon On Mon, Jan 31, 2011 at 09:12:10PM +0100, Jeremias Maerki wrote: Hi Simon Huh? What revision are you looking at? I've merged Trunk into Temp_Color on January 18 (http://svn.apache.org/viewvc?rev=1060241view=rev) copying the XGC.jar unchanged from Trunk. Temp_Color is long working against java2d.color and is compiling just fine like that. Looking at the XGC.jar in Trunk OTOH, it contains some junk in the root directory and test classes further down the hierarchy. If anything we need to rebuild the XGC.jar from Trunk and do another merge into Temp_Color. Something must have gone wrong during the compilation of that JAR. http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_Color/lib/xmlgraphics-commons-1.5svn.jar?view=logpathrev=1060241 I'll look at your other points shortly. Thanks for the review.
DO NOT REPLY [Bug 50698] New: [PATCH] Synchronize access to java.awt.ICC_Profile
https://issues.apache.org/bugzilla/show_bug.cgi?id=50698 Summary: [PATCH] Synchronize access to java.awt.ICC_Profile Product: Fop Version: 1.1dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: adelme...@apache.org Created an attachment (id=26588) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26588) proposed patch addressing potential issue in FOP In response to a recent post on fop-users@ (see: http://marc.info/?l=fop-userm=129646673801270w=2), the attached patch: - adds two methods to fop.util.ColorProfileUtil that perform calls to ICC_Profile.getInstance() in a synchronized fashion (only the InputStream and int variants are used) - replaces all direct calls to ICC_Profile.getInstance() in FOP's code with calls to one of those new methods Note: The issue mentioned in the original post is *not* addressed by this patch, as that instance of the issue arises somewhere in XMLGraphics. Probably a good step to take towards solving this in XG, is to migrate the ColorProfileUtil class there, and have FOP reference that one. -- 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 50698] [PATCH] Synchronize access to java.awt.color.ICC_Profile
https://issues.apache.org/bugzilla/show_bug.cgi?id=50698 Andreas L. Delmelle adelme...@apache.org changed: What|Removed |Added Summary|[PATCH] Synchronize access |[PATCH] Synchronize access |to java.awt.ICC_Profile |to ||java.awt.color.ICC_Profile -- 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 49835] Wrong page break with 2 columned region and tables
https://issues.apache.org/bugzilla/show_bug.cgi?id=49835 Andreas L. Delmelle adelme...@apache.org changed: What|Removed |Added OS/Version||All --- Comment #6 from Andreas L. Delmelle adelme...@apache.org 2011-02-01 07:15:00 EST --- Operating on a hunch, I tried prepending each blockList in AbstractBreaker.doLayout() with an auxiliary penalty (w=0, p=0). At line 394, I added a simple: blockList.add(0, new KnuthPenalty(0, 0, false, null, true)); It seems to trigger correct behavior in this case, as the entire block is now deferred to the second page, where it can be kept together in one column. On the other hand, that quick hack breaks quite some testcases. All those that check for element-list content now suddenly have to deal with an extra element at position 0... Fact remains that, without this penalty, the last forced node points to position 0, which corresponds to the first box, while it should actually point to the position preceding the first box. -- 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 50698] [PATCH] Synchronize access to java.awt.color.ICC_Profile
https://issues.apache.org/bugzilla/show_bug.cgi?id=50698 --- Comment #1 from Jeremias Maerki jerem...@apache.org 2011-02-01 07:19:08 EST --- As you suggested, I'd move ColorProfileUtil over to XGC and apply the changes for that class there. Batik suffers from the same problem apparently (SVGColorProfileElementBridge). Thanks for looking into it. You actually beat me to it. I wanted to do something similar. -- 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: [VOTE] Merge FOP color branch into trunk
Hmm, I don't see how any cruft can accumulate in there. Main and test classes are properly separated. jar-main only packs build/classes. Anyway, when Andreas moves ColorProfileUtil to XGC (or shall I, Andreas?), we need to update the JAR anyway. On 01.02.2011 12:06:56 Simon Pepping wrote: You are right. I got confused by various issues in my tools. The jar file was built by 'ant jar-main'. This target includes all cruft that is present in the build directory. The build files could do with an includes attribute in the jar task. Simon On Mon, Jan 31, 2011 at 09:12:10PM +0100, Jeremias Maerki wrote: Hi Simon Huh? What revision are you looking at? I've merged Trunk into Temp_Color on January 18 (http://svn.apache.org/viewvc?rev=1060241view=rev) copying the XGC.jar unchanged from Trunk. Temp_Color is long working against java2d.color and is compiling just fine like that. Looking at the XGC.jar in Trunk OTOH, it contains some junk in the root directory and test classes further down the hierarchy. If anything we need to rebuild the XGC.jar from Trunk and do another merge into Temp_Color. Something must have gone wrong during the compilation of that JAR. http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_Color/lib/xmlgraphics-commons-1.5svn.jar?view=logpathrev=1060241 I'll look at your other points shortly. Thanks for the review. Jeremias Maerki
DO NOT REPLY [Bug 50699] New: Problem with greek glyphnames using type1 font for postscript output
https://issues.apache.org/bugzilla/show_bug.cgi?id=50699 Summary: Problem with greek glyphnames using type1 font for postscript output Product: Fop Version: all Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: ps AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: alpa...@gmail.com We have an issue regarding the generation of postscript documents using a custom type1 font in the greek language. The font we tried is called kerkis (can be found @ http://iris.math.aegean.gr/kerkis/Kerkis_for_LaTeX.zip), but the same behaviour is observed using true type fonts that we have converted to type1 using open source tools (like fontforge). Trying to render the attached sample.fo with the config given, Fop complaints with the following message: org.apache.fop.events.LoggingEventListener processEvent WARNING: Glyph ? (0x394, Deltagreek) not available in font Kerkis. org.apache.fop.events.LoggingEventListener processEvent WARNING: Glyph O (0x3a9, Omegagreek) not available in font Kerkis. Our fonts, have glyphs named Omega and Delta - only. Browsing around we found that basically, the code 0x3a9 is equivalent to 0x2126 (Omega) and 0x394 to 0x2206 (Delta). Apparently there are other codes for the Cyrilic version of Omega and Delta, that actually point to the same glyph. These are all defined in xmlgraphics-commons library, in org.apache.xmlgraphics.fonts.Glyphs classm put they point to different glyph names, like: Omega;2126 Omegacyrillic;0460 Omegagreek;03A9 Omegaroundcyrillic;047A Omegatitlocyrillic;047C And Delta;2206 Deltagreek;0394 Fop uses this class to resolve codes to glyph names, and then uses this name to look the glyph in the font, thus producing the error you see. The patch fixes the error, what might be missing, is filling the map with a not found symbol, for the case were no alternatives were found... -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
PreviewPanel
FOP provides org.apache.fop.render.awt.viewer.PreviewPanel but it's ugly. I'm running a client-server program through webstart. My programs run on the server and of course all GUI objects need to be created on the client. The PreviewPanel requires a Java transformer and a Renderer to be created on the client, both of which may take a long time, at least the first time. They run faster if you run them more than once so they're cached but my goal is not to create them at all. So I'm creating my own PreviewPanel with no transformer and no Renderer. This will display an image, so I require a couple of enhancements. The first task is creating this new panel object. So I'm looking at FOP's PreviewPanel to copy some of that logic and I'm confused. What is the gridPanel object? PreviewPanel extends JPanel but contains an object of type JPanel? Is it creating a panel within a panel? What's the point of that? From what I've found my object should need to (extend type or contain an object of type?) org.jdesktop.swingx.JXPanel to use an org.jdesktop.swingx.painter.ImagePainter to draw the picture. My second enhancement I'd like to add would be to do this without writing any files to disk. For the normal transform I'm generating the entire output programatically so writing the XML, FO, or PDF files are all optional. I get the output from Fop in a byte stream which I can use to either create a Pageable PDF object through pdfbox and send to the printer without writing to disk or I can clone down to the client to save as a PDF on their machine. The PNGRenderer only option is to generate each page as a physical file on disk. I'll want to update this renderer or write a new one based on it to be able to send the pages to the byte stream instead, or an array of byte streams one per page.
Re: [VOTE] Merge FOP color branch into trunk
On 01 Feb 2011, at 13:24, Jeremias Maerki wrote: Hmm, I don't see how any cruft can accumulate in there. Main and test classes are properly separated. jar-main only packs build/classes. Anyway, when Andreas moves ColorProfileUtil to XGC (or shall I, Andreas?), we need to update the JAR anyway. Sure, I can take care of the migration of ColorProfileUtil in the same go. Do we move it to java2d.color.profile (similar to ColorUtil, which is placed under java2d.color)? See attached patch XGC_ColorProfileUtil for the proposal. Just added a method to deal with the getInstance(byte[]) variant used in XGC, and for the sake of completeness, provided one for the String variant as well. Additionally, looked up the places where one of the getInstance() methods was being used and replaced them by a corresponding call to ColorProfileUtil.getICC_Profile(). As it turns out, there were only two occurrences: ImageLoaderRawJPEG and ImageLoaderImageIO. Are there any special steps to be taken to replace the JAR in FOP, or do I just commit the new '...1.5svn' JAR? On FOP's end, after the JAR has been replaced, the changes then become as in attached patch FOP_ColorProfileUtil. For now, I deprecated the class and redirected the existing methods. The calls to getICC_Profile() are done directly against XGC, so no need to add those to FOP's ColorProfileUtil anymore. I also cleaned up the remaining references to other methods (= basically just replaced import statements in the affected classes), so fop.util.ColorProfileUtil is actually unused. To be removed at a later date? The harder part would be to come up with some test cases, in order to verify that this actually fixes the behavior... Notoriously difficult in the case of race conditions, especially if they are located in code that is outside of our control. XGC_ColorProfileUtil.diff Description: Binary data FOP_ColorProfileUtil.diff Description: Binary data Regards, Andreas ---
Re: [VOTE] Merge FOP color branch into trunk
Looks perfect. Thanks! If it's not too much trouble, please svn copy the ColorProfileUtil from FOP Trunk so we retain the history and document where this came from. I don't think it makes sense to put a lot of time in trying to test for a race condition. That's going to be difficult to reproduce. And to prove that it's no longer there. For me, the important thing is that this problem is documented in ColorProfileUtil like you did. For the JAR: just do a clean compile (with Java 1.5, i.e. lowest possible) and replace the ...1.5svn.jar in FOP's lib directory. On 01.02.2011 19:40:38 Andreas Delmelle wrote: On 01 Feb 2011, at 13:24, Jeremias Maerki wrote: Hmm, I don't see how any cruft can accumulate in there. Main and test classes are properly separated. jar-main only packs build/classes. Anyway, when Andreas moves ColorProfileUtil to XGC (or shall I, Andreas?), we need to update the JAR anyway. Sure, I can take care of the migration of ColorProfileUtil in the same go. Do we move it to java2d.color.profile (similar to ColorUtil, which is placed under java2d.color)? See attached patch XGC_ColorProfileUtil for the proposal. Just added a method to deal with the getInstance(byte[]) variant used in XGC, and for the sake of completeness, provided one for the String variant as well. Additionally, looked up the places where one of the getInstance() methods was being used and replaced them by a corresponding call to ColorProfileUtil.getICC_Profile(). As it turns out, there were only two occurrences: ImageLoaderRawJPEG and ImageLoaderImageIO. Are there any special steps to be taken to replace the JAR in FOP, or do I just commit the new '...1.5svn' JAR? On FOP's end, after the JAR has been replaced, the changes then become as in attached patch FOP_ColorProfileUtil. For now, I deprecated the class and redirected the existing methods. The calls to getICC_Profile() are done directly against XGC, so no need to add those to FOP's ColorProfileUtil anymore. I also cleaned up the remaining references to other methods (= basically just replaced import statements in the affected classes), so fop.util.ColorProfileUtil is actually unused. To be removed at a later date? The harder part would be to come up with some test cases, in order to verify that this actually fixes the behavior... Notoriously difficult in the case of race conditions, especially if they are located in code that is outside of our control. Jeremias Maerki
DO NOT REPLY [Bug 50698] [PATCH] Synchronize access to java.awt.color.ICC_Profile
https://issues.apache.org/bugzilla/show_bug.cgi?id=50698 Andreas L. Delmelle adelme...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Andreas L. Delmelle adelme...@apache.org 2011-02-01 15:06:29 EST --- Alternate approach taken as proposed. Changes to FOP committed in r1066182 (http://svn.apache.org/viewvc?rev=1066182view=rev) -- 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: [VOTE] Merge FOP color branch into trunk
On 01 Feb 2011, at 20:23, Jeremias Maerki wrote: Looks perfect. Thanks! If it's not too much trouble, please svn copy the ColorProfileUtil from FOP Trunk so we retain the history and document where this came from. Done. All related changes committed to both XGC and FOP. Regards, Andreas ---
DO NOT REPLY [Bug 48334] [PATCH] xml:base
https://issues.apache.org/bugzilla/show_bug.cgi?id=48334 Andreas L. Delmelle adelme...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Andreas L. Delmelle adelme...@apache.org 2011-02-01 15:28:02 EST --- Patch applied as proposed in r1066190 (http://svn.apache.org/viewvc?rev=1066190view=rev) -- 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 50703] New: [PATCH] Parametrize PropertyCache
https://issues.apache.org/bugzilla/show_bug.cgi?id=50703 Summary: [PATCH] Parametrize PropertyCache Product: Fop Version: 1.1dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: fo tree AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: adelme...@apache.org Created an attachment (id=26590) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26590) proposed patch Attached patch parametrizes fop.fo.properties.PropertyCache. As a result, all the different public fetch() overloads can be rolled into one, and suddenly this class seems to have the potential for more general usage. Any class offering reliable implementations for equals() and hashCode() is now a candidate to store its canonical instances in the cache. The idiom becomes: PropertyCacheType cache = new PropertyCacheType(Type.class); The constructor parameter is still needed, as I could not immediately find a way to derive the class name (for debugging) from the type parameter. Don't know if there even is one... At any rate, the correspondence between constructor and type parameter is enforced by the constructor, so it would not be possible to write: new PropertyCacheTypeA(TypeB.class) not even if TypeB is a subclass of TypeA. If I judge correctly, applying this patch by itself should, at worst, cause a few unchecked warnings to pop up in the fo.properties package. Locally, I have already adapted all the properties that use it (and added a few new classes), but I kept these changes out of the patch for now, to focus on the main change. Suggestions welcome. Would it be useful outside of the fo.properties package as well? Could it migrate to fop.util? -- 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 50703] [PATCH] Parametrize PropertyCache
https://issues.apache.org/bugzilla/show_bug.cgi?id=50703 Andreas L. Delmelle adelme...@apache.org changed: What|Removed |Added Attachment #26590|application/octet-stream|text/plain mime type|| Attachment #26590|0 |1 is patch|| -- 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: svn commit: r1066275 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr: KnuthPossPosIter.java PositionIterator.java
On 02 Feb 2011, at 00:46, adelme...@apache.org wrote: Author: adelmelle Date: Tue Feb 1 23:46:38 2011 New Revision: 1066275 URL: http://svn.apache.org/viewvc?rev=1066275view=rev Log: Add type safety to PositionIterator + attempt at javadoc improvement Note: while going over this, the current situation struck me as slightly awkward. I am unsure of the original intentions when it was implemented, but the fact is that we now have five PositionIterator subclasses, four of which override the abstract getPos() and getLM() methods to do exactly the same thing... Proposed alternative? Make PositionIterator non-abstract, provide default implementations for getPos() and getLM(), and use the type directly, instead of those scattered StackingIter inner classes in the LMs which are basically copies of each other. Other suggestions to clean this up a bit? Regards, Andreas ---
Re: [VOTE] Merge FOP color branch into trunk
Thanks, Andreas! On 01.02.2011 21:09:15 Andreas Delmelle wrote: On 01 Feb 2011, at 20:23, Jeremias Maerki wrote: Looks perfect. Thanks! If it's not too much trouble, please svn copy the ColorProfileUtil from FOP Trunk so we retain the history and document where this came from. Done. All related changes committed to both XGC and FOP. Regards, Andreas --- Jeremias Maerki
