DO NOT REPLY [Bug 47711] New: [PATCH] Wrong CIDSet when embedding CID font subset in a PDF.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47711 Summary: [PATCH] Wrong CIDSet when embedding CID font subset in a PDF. Product: Fop Version: all Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: pdf AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: n...@lostgeeks.org --- Comment #0 from Nicolas PENINGUY n...@lostgeeks.org 2009-08-20 00:19:06 PDT --- Created an attachment (id=24153) Simple fix The /CIDSet entry should contain glyph index in the subset, not in the original font. -- 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 47711] [PATCH] Wrong CIDSet when embedding CID font subset in a PDF.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47711 Nicolas PENINGUY n...@lostgeeks.org changed: What|Removed |Added Attachment #24153|application/octet-stream|text/plain mime type|| Attachment #24153|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.
AW: Referencing multiple pages for index entries
Hi Laurent, The index page is indeed the very last page, but since I still have the fo file, I can add further indizes and cover pages later. I just don't have them at the moment and I don't need them for the correct page numbers of the index, so I can look for the last page. You might as well use a table to display your entries and find the table by id instead of the page. Actually, I wouldn't need to find the page at all, since I search for the entries directly in my xpath statement, but stripping the unneeded nodes reduces the time needed to find all the page numbers from 2 hours to 2 minutes with even medium sized documents! prod-id is the area tree name for the id attribute of fo-elements. Each page-number-citation element gets a (of course) unique id and I keep a map of which elements belong to which entries. Then I get the ids and the actual page numbers from the area tree and can strip page-number-citation elements from the fo file. Using id/prod-id is robust, since it can't be confused by user content and fop requires ids to be unique anyway. Mit freundlichen Grüßen Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH:www.irs-nbg.de Willmy PrintMedia GmbH:www.willmy.de Willmy Consult Content GmbH: www.willmycc.de -Ursprüngliche Nachricht- Von: Laurent Caillette [mailto:laurent.caille...@ullink.com] Gesendet: Mittwoch, 19. August 2009 18:15 An: fop-dev@xmlgraphics.apache.org Betreff: RE: Referencing multiple pages for index entries Thanks Georg. As far as I understand your code, the page containing index entries is the very last child of the DOM tree and the ``prod-id`` attribute contains some kind of unique identifier corresponding to a known page. Am I right? I'd like to allow other page sequences following index entries, and those may span on several pages, so last DOM child may not be the right one to search into. That's why I'm asking for a robust mechanism to surround index keys and page numbers. For sure I could use magic text like XxxxSTARTxxxX and XxxxENDxxxX but this could be fooled by any user content. Looking at the IF draft on FOP wiki I see there is a page-name attribute for the page. Setting such a an attribute value (not necessarily this one) from FO would save me, then. c. -Message d'origine- De : Georg Datterl [mailto:georg.datt...@geneon.de] Envoyé : mercredi 19 août 2009 15:20 À : fop-dev@xmlgraphics.apache.org Objet : AW: Referencing multiple pages for index entries Hi Laurent, In real world use cases, it's acceptable to support index entries only at the end of the numbering sequence or in another numbering sequence, so let's do post-processing. There are plenty of issues to solve but they are mostly related to `I/Os` and XSL and Novelang design so I won't discuss them in this list. I'm just thinking: If we are restricted to an index in a separate page-sequence after the actual entries, wouldn't it be possible DURING the layout (when creating the KnuthSequence?) to look forward (or back) and modify the entries (which already should know their page number), and then layout once? One question left, however. I wonder how to hint FO document for generating Area Tree or Intermediate Format that I could reparse easily, for locating pages containing index entries, and extracting index keys and lists of page numbers. __ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 4348 (20090819) __ Le message a été vérifié par ESET NOD32 Antivirus. http://www.eset.com
Re: Moving to Java 1.5, retroweaving for 1.4 (was: svn commit: r805561 [1/2]....)
There we go again. ;-) I can understand the wishes and cravings of the developers (feeling them myself), but as I've said before: such a decision should be made with the user community in the back, i.e. there should be another user survey to gather current data. Just because Sun EOLs a Java version doesn't mean that everyone can suddenly just do the switch. So why don't those who want this change so badly do that little survey so we have the data on an informed decision? As for retroweaving: I've just set the necessary values in my build-local.properties and tried to compile the latest FOP Trunk with Java 1.5. The build failed in the retroweaver task: --- retro-avail: [mkdir] Created dir: C:\Dev\FOP\main\trunk-clean2\build\temp [retroweaver] Processing 1775 classes [retroweaver] 1775 classes weaved. [retroweaver] Verifying 1775 classes [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isLowerCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c ould not be located: net/sourceforge/retroweaver/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isUpperCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c ould not be located: net/sourceforge/retroweaver/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isTitleCase/(I)Z, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toLowerCase/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method getType/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method of/(I)Ljava.lang.Character$UnicodeBlock;, Method not found in java.lang.Character$Unicod eBlock [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toUpperCase/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toTitleCase/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/runtime/java/lang/Character_ [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE$EncryptionFilter: unknown class javax.crypto.CipherOutputStream [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method doFinal/([B)[B, The class, javax.crypto.Cipher, could not be located: javax/crypto/Cipher [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method getMessage/()Ljava.lang.String;, The class, javax.crypto.IllegalBlockSizeException, could not be located: javax/crypto/IllegalBlockSizeException [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method getMessage/()Ljava.lang.String;, The class, javax.crypto.BadPaddingException, could not be loc ated: javax/crypto/BadPaddingException [retroweaver]
RE: Referencing multiple pages for index entries
Thanks Georg, Those ids are good news. Now I need to experiment a bit, then things wil get clearer I think. Intermediate Format looks like a good choice for such a hack but I've downloaded a FOP snapshot (805900) and the ``IntermediateFormatTestSuite`` takes forever (running Ant default target under Windows XP with `Ant-1.7.0`). Hope this will be fixed soon! Yesterday evening I had a look at the FOP code with your other proposal about Knuth Sequence in mind. Well, that's too hard for me yet and I'll take the easy (hum) way for the moment. Regards, c. -Message d'origine- De : Georg Datterl [mailto:georg.datt...@geneon.de] Envoyé : jeudi 20 août 2009 10:11 À : fop-dev@xmlgraphics.apache.org Objet : AW: Referencing multiple pages for index entries Hi Laurent, The index page is indeed the very last page, but since I still have the fo file, I can add further indizes and cover pages later. I just don't have them at the moment and I don't need them for the correct page numbers of the index, so I can look for the last page. You might as well use a table to display your entries and find the table by id instead of the page. Actually, I wouldn't need to find the page at all, since I search for the entries directly in my xpath statement, but stripping the unneeded nodes reduces the time needed to find all the page numbers from 2 hours to 2 minutes with even medium sized documents! prod-id is the area tree name for the id attribute of fo-elements. Each page-number-citation element gets a (of course) unique id and I keep a map of which elements belong to which entries. Then I get the ids and the actual page numbers from the area tree and can strip page-number-citation elements from the fo file. Using id/prod-id is robust, since it can't be confused by user content and fop requires ids to be unique anyway. Mit freundlichen Grüßen Georg Datterl __ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 4350 (20090820) __ Le message a été vérifié par ESET NOD32 Antivirus. http://www.eset.com
Re: Moving to Java 1.5, retroweaving for 1.4 (was: svn commit: r805561 [1/2]....)
On 20/08/2009, at 7:41 PM, Jeremias Maerki wrote: There we go again. ;-) I can understand the wishes and cravings of the developers (feeling them myself), but as I've said before: such a decision should be made with the user community in the back, i.e. there should be another user survey to gather current data. Just because Sun EOLs a Java version doesn't mean that everyone can suddenly just do the switch. So why don't those who want this change so badly do that little survey so we have the data on an informed decision? As for retroweaving: I've just set the necessary values in my build-local.properties and tried to compile the latest FOP Trunk with Java 1.5. The build failed in the retroweaver task: --- retro-avail: [mkdir] Created dir: C:\Dev\FOP\main\trunk-clean2\build\temp [retroweaver] Processing 1775 classes [retroweaver] 1775 classes weaved. [retroweaver] Verifying 1775 classes [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isLowerCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c ould not be located: net/sourceforge/retroweaver/runtime/java/lang/ Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isUpperCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c ould not be located: net/sourceforge/retroweaver/runtime/java/lang/ Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isTitleCase/(I)Z, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toLowerCase/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method getType/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method of/(I)Ljava.lang.Character$UnicodeBlock;, Method not found in java.lang.Character$Unicod eBlock [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toUpperCase/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toTitleCase/(I)I, Method not found in java.lang.Character [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method toChars/(I)[C, The class, net.sourceforge.retroweaver.harmony.runtime.java.lang.Characte r_, could not be located: net/sourceforge/retroweaver/harmony/ runtime/java/lang/Character_ [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE$EncryptionFilter: unknown class javax.crypto.CipherOutputStream [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method doFinal/([B)[B, The class, javax.crypto.Cipher, could not be located: javax/crypto/Cipher [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method getMessage/()Ljava.lang.String;, The class, javax.crypto.IllegalBlockSizeException, could not be located: javax/crypto/IllegalBlockSizeException [retroweaver] org.apache.fop.pdf.PDFEncryptionJCE: unknown method getMessage/()Ljava.lang.String;, The class,
AW: Referencing multiple pages for index entries
Hi Laurent, Those ids are good news. Now I need to experiment a bit, then things wil get clearer I think. Yes, the id attribute is the most usefull attribute when working with the area tree. :-) Intermediate Format looks like a good choice for such a hack but I've downloaded a FOP snapshot (805900) and the ``IntermediateFormatTestSuite`` takes forever (running Ant default target under Windows XP with `Ant-1.7.0`). Hope this will be fixed soon! Well, you don't need that too often. Only when generating a build. Yesterday evening I had a look at the FOP code with your other proposal about Knuth Sequence in mind. Well, that's too hard for me yet and I'll take the easy (hum) way for the moment. I don't understand the theory behind it either but if I'm not mistaken, you can look at the sequence of KnuthElements as just a chain of small text areas separated by spaces (=penalties) and break-possibilities. But before I make a complete fool out of myself, I better leave that topics to the experts. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH:www.irs-nbg.de Willmy PrintMedia GmbH:www.willmy.de Willmy Consult Content GmbH: www.willmycc.de -Ursprüngliche Nachricht- Von: Laurent Caillette [mailto:laurent.caille...@ullink.com] Gesendet: Donnerstag, 20. August 2009 11:46 An: fop-dev@xmlgraphics.apache.org Betreff: RE: Referencing multiple pages for index entries Thanks Georg, Those ids are good news. Now I need to experiment a bit, then things wil get clearer I think. Intermediate Format looks like a good choice for such a hack but I've downloaded a FOP snapshot (805900) and the ``IntermediateFormatTestSuite`` takes forever (running Ant default target under Windows XP with `Ant-1.7.0`). Hope this will be fixed soon! Yesterday evening I had a look at the FOP code with your other proposal about Knuth Sequence in mind. Well, that's too hard for me yet and I'll take the easy (hum) way for the moment. Regards, c. -Message d'origine- De : Georg Datterl [mailto:georg.datt...@geneon.de] Envoyé : jeudi 20 août 2009 10:11 À : fop-dev@xmlgraphics.apache.org Objet : AW: Referencing multiple pages for index entries Hi Laurent, The index page is indeed the very last page, but since I still have the fo file, I can add further indizes and cover pages later. I just don't have them at the moment and I don't need them for the correct page numbers of the index, so I can look for the last page. You might as well use a table to display your entries and find the table by id instead of the page. Actually, I wouldn't need to find the page at all, since I search for the entries directly in my xpath statement, but stripping the unneeded nodes reduces the time needed to find all the page numbers from 2 hours to 2 minutes with even medium sized documents! prod-id is the area tree name for the id attribute of fo-elements. Each page-number-citation element gets a (of course) unique id and I keep a map of which elements belong to which entries. Then I get the ids and the actual page numbers from the area tree and can strip page-number-citation elements from the fo file. Using id/prod-id is robust, since it can't be confused by user content and fop requires ids to be unique anyway. Mit freundlichen Grüßen Georg Datterl __ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 4350 (20090820) __ Le message a été vérifié par ESET NOD32 Antivirus. http://www.eset.com
Re: svn commit: r805561 [1/2] - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/hyphenation/ src/java/org/apache/fop/tools/anttasks/
Hi Simon, Simon Pepping wrote: On Wed, Aug 19, 2009 at 08:44:03AM +0200, Jeremias Maerki wrote: Uhm, Simon, this change uses tons of Java 1.5 features. The build fails now on Java 1.4. OK if we revert until you've had a chance to revisit? I am surprised. My eclipse project is set to 1.4 compatibility for comiler compliance level, generated .class files compatibility, source compatibility. Which part is not compatible with 1.4? Although the source code is 1.4-compatible, calls are made to methods that were only added in the Java 1.5 release. So a 1.4 JRE won’t find them. Revert it if that is needed to keep trunk compilable. I will not immediately have time to revisit this. Simon Vincent
[VOTE] Merge the ChangingIPDHack Branch Back to Trunk
Hi All, Having had no feedback from the users list, I’m happy to announce that the ChangingIPDHack branch is now totally bug-free :-) Following the discussion on general@ [1], the best way to handle this probably is to merge the changes back into the Trunk, even if they are hacky. Maintaining a separate branch may turn out to be more time-consuming than reverting the merge once work on a new layout engine starts. So I’d like to launch a vote for merging the following branch: https://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ChangingIPDHack into Trunk. +1 from me. [1] http://markmail.org/message/ypn2p6c27gjx3vzi Thanks, Vincent
Re: [VOTE] Merge the ChangingIPDHack Branch Back to Trunk
On 20.08.2009 13:42:48 Vincent Hennebert wrote: Hi All, Having had no feedback from the users list, I’m happy to announce that the ChangingIPDHack branch is now totally bug-free :-) You ready to bet money on that? ;-) Following the discussion on general@ [1], the best way to handle this probably is to merge the changes back into the Trunk, even if they are hacky. Maintaining a separate branch may turn out to be more time-consuming than reverting the merge once work on a new layout engine starts. So I’d like to launch a vote for merging the following branch: https://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ChangingIPDHack into Trunk. +1 from me. Agreed with the argumentation. +1 from me. The changes seem well backed by tests and they appear to break no existing tests. This is useful functionality for some people. Better have as few parallel branches as possible. Reminds me to do something about the Tagged PDF branch when I have a chance. [1] http://markmail.org/message/ypn2p6c27gjx3vzi Thanks, Vincent Jeremias Maerki
Re: [VOTE] Merge the ChangingIPDHack Branch Back to Trunk
Sorry Vincent but I have no time to test your work at the moment. Hacks are rarely satisifying, but it seems that you have made the best of a constraining situation, +1 from me. Adrian. Vincent Hennebert wrote: Hi All, Having had no feedback from the users list, I’m happy to announce that the ChangingIPDHack branch is now totally bug-free :-) Following the discussion on general@ [1], the best way to handle this probably is to merge the changes back into the Trunk, even if they are hacky. Maintaining a separate branch may turn out to be more time-consuming than reverting the merge once work on a new layout engine starts. So I’d like to launch a vote for merging the following branch: https://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ChangingIPDHack into Trunk. +1 from me. [1] http://markmail.org/message/ypn2p6c27gjx3vzi Thanks, Vincent
Re: [VOTE] Merge the ChangingIPDHack Branch Back to Trunk
Vincent Hennebert wrote: Hi All, Thanks for starting the vote Vincent. Having had no feedback from the users list, I’m happy to announce that the ChangingIPDHack branch is now totally bug-free :-) Following the discussion on general@ [1], the best way to handle this probably is to merge the changes back into the Trunk, even if they are hacky. Maintaining a separate branch may turn out to be more time-consuming than reverting the merge once work on a new layout engine starts. Yes I agree with that :) So I’d like to launch a vote for merging the following branch: https://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ChangingIPDHack into Trunk. +1 from me. I've run a few real life test documents against the branch and found no problems. So +1 from me. Thanks, Chris [1] http://markmail.org/message/ypn2p6c27gjx3vzi Thanks, Vincent
Re: Moving to Java 1.5, retroweaving for 1.4 (was: svn commit: r805561 [1/2]....)
Thanks for the retroweaver report. I believe I removed all methods which are not Java 1.4 compliant. I tried to do a compilation in Java 1.4, but I failed with an UnsupportedClassVersionError, which I am not going to investigate now. So I could not test this myself. Simon On Thu, Aug 20, 2009 at 11:41:27AM +0200, Jeremias Maerki wrote: As for retroweaving: I've just set the necessary values in my build-local.properties and tried to compile the latest FOP Trunk with Java 1.5. The build failed in the retroweaver task: --- retro-avail: [mkdir] Created dir: C:\Dev\FOP\main\trunk-clean2\build\temp [retroweaver] Processing 1775 classes [retroweaver] 1775 classes weaved. [retroweaver] Verifying 1775 classes [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isLowerCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c ould not be located: net/sourceforge/retroweaver/runtime/java/lang/Character_ [retroweaver] org.apache.fop.hyphenation.UnicodeClasses: unknown method isUpperCase/(I)Z, The class, net.sourceforge.retroweaver.runtime.java.lang.Character_, c ould not be located: net/sourceforge/retroweaver/runtime/java/lang/Character_ ... BUILD FAILED C:\Dev\FOP\main\trunk-clean2\build.xml:519: 28 warning(s) Jeremias Maerki wrote: Uhm, Simon, this change uses tons of Java 1.5 features. The build fails now on Java 1.4. OK if we revert until you've had a chance to revisit? -- Simon Pepping home page: http://www.leverkruid.eu
Re: Moving to Java 1.5, retroweaving for 1.4
On Thu, Aug 20, 2009 at 02:14:39PM +0100, Chris Bowditch wrote: Jeremias Maerki wrote: There we go again. ;-) I can understand the wishes and cravings of the developers (feeling them myself), but as I've said before: such a decision should be made with the user community in the back, i.e. there should be another user survey to gather current data. Just because Sun EOLs a Java version doesn't mean that everyone can suddenly just do the switch. So why don't those who want this change so badly do that little survey so we have the data on an informed decision? Hi All, I'm not so against this idea 1 year further on but I still have concerns that we would force x% of users to stay on 0.95 if we do this. I agree with Jeremias' proposal to run a survey on fop-users for a couple of weeks to get some hard facts to help make an informed decision. Also, I think it is something that could wait until after the long promised 1.0 release. With the changing IPD feature being one of the last major features of 0.20.x missing from 0.9x that is now available we should consider doing the v1.0 release and then if the survey shows the number of 1.4 and earlier users to be very low then we should do the switch. I agree that we should proceed with a 1.0 release. I can also agree with releasing it compliant with Java 1.4. I note, however, that the methods I removed were several methods in class Character which are very useful in character handling, such as the method Character.toChars(int), which is the main method to convert an integer to an array of chars. That means that for Unicode values above 0x there is no good method to turn the value into a char[] or String. Also Characters.toLowerCase, toUpperCase, toTitleCase, getType, $UnicodeBlock. For a text handling application in 2009 that is a bit painful. Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: AW: Referencing multiple pages for index entries
On 20 Aug 2009, at 12:10, Georg Datterl wrote: Hi Georg, Laurent, Yesterday evening I had a look at the FOP code with your other proposal about Knuth Sequence in mind. Well, that's too hard for me yet and I'll take the easy (hum) way for the moment. I don't understand the theory behind it either but if I'm not mistaken, you can look at the sequence of KnuthElements as just a chain of small text areas separated by spaces (=penalties) and break- possibilities. But before I make a complete fool out of myself, I better leave that topics to the experts. Basically not bad as an interpretation, although KnuthElements are generated that represent border, padding etc. rather than merely 'text fragments'. And OTOH, penalties actually do not correspond to spaces. Penalties represent break-possibilities (or -impossibilities if penalty=INFINITE). Spaces, in the most common case, correspond to KnuthGlue objects, which are a break-possibility only if they are preceded by a KnuthBox. In many cases, FOP generates a sequence of penalty-box-glue for a space (to avoid a break before, or to hint at what happens if there is a break before --i.e. how much width should be added to the line when choosing that possibility as an effective break) Regards Andreas Andreas Delmelle mailto:andreas.delmelle.AT.telenet.be jabber: mandr...@jabber.org skype: adlm0608 ---
Re: [VOTE] Merge the ChangingIPDHack Branch Back to Trunk
On 20 Aug 2009, at 13:42, Vincent Hennebert wrote: snip / So I’d like to launch a vote for merging the following branch: https://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ChangingIPDHack into Trunk. Like Adrian, I haven't been able to allocate the time to run tests of my own, but IMO, the changes have been up for review long enough now. So +1 from my end. Regards Regards, Andreas Delmelle mailto:andreas.delmelle.AT.telenet.be jabber: mandr...@jabber.org skype: adlm0608 ---
DO NOT REPLY [Bug 47710] NullPointerException related to white-space handling in retrieved markers
https://issues.apache.org/bugzilla/show_bug.cgi?id=47710 --- Comment #3 from Andreas L. Delmelle adelme...@apache.org 2009-08-20 14:19:21 PDT --- Quick fix committed in r806361. I'm inclined to leave this bug open for the moment, as this is not really the cleanest way to solve it. The real issue may ultimately still cause incorrect preservation of trailing white-space in such markers. Likely to be hardly noticeable, but still... -- 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 the ChangingIPDHack Branch Back to Trunk
Another 'No time to test it!' +1 from me... Clay On 8/20/09, Vincent Hennebert vhenneb...@gmail.com wrote: Hi All, Having had no feedback from the users list, I’m happy to announce that the ChangingIPDHack branch is now totally bug-free :-) Following the discussion on general@ [1], the best way to handle this probably is to merge the changes back into the Trunk, even if they are hacky. Maintaining a separate branch may turn out to be more time-consuming than reverting the merge once work on a new layout engine starts. So I’d like to launch a vote for merging the following branch: https://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_ChangingIPDHack into Trunk. +1 from me. [1] http://markmail.org/message/ypn2p6c27gjx3vzi Thanks, Vincent -- Regards, The Web Maestro -- the.webmaes...@gmail.com - http://ourlil.com/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
