DO NOT REPLY [Bug 42109] - [PATCH] ZWSP works as backspace when font is embedded
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42109. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42109 --- Additional Comments From [EMAIL PROTECTED] 2007-04-13 01:32 --- Thanks for spotting this and submitting a patch. Good work. Bug Confirmed. I tested your FO with Arial in PDF and the same affect occured. I was a little concerned that your fix was PDF specific, so I tried to recreate the issue in Postscript but the bug doesn't seem to affect the Postscript Renderer. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 41995] - [PATCH] Barcode Support for AFP Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41995. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41995 --- Additional Comments From [EMAIL PROTECTED] 2007-04-13 05:02 --- Created an attachment (id=19947) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19947action=view) Fix to change setters from int to double Fix to change setters from int to double -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Comments on the AFP output
Yesterday, I've shown FOP to an AFP specialist. He was quite impressed and he said that the AFP generated is much better than many things he's seen from established, commercial applications. So congrats to those involved in the AFP Renderer! He has, of course, found a few things he'd improve (like the resolution being fixed to 240dpi or the way white text is painted on a non-transparent background). He implied that he may drop in at some point and help us improve the implementation. Let's hope he does. I'll keep prodding... Jeremias Maerki
Re: Comments on the AFP output
Thanks for the update, Jeremias! Hearing that our AFP Renderer is so well-received is great news! Web Maestro Clay -- Regards, The Web Maestro -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: Change to support named destination and test files
Can somebody please test the files I deposited here? http://people.apache.org/~jeremias/fop/dest-test/ Those are made from Paul's FO files. I took a look myself and compared the current behaviour to what was in 0.20.5. First observation: Adobe Acrobat doesn't list any destinations when the PDF is created with FOP Trunk, but it does if you generate the PDF with FOP 0.20.5. So I went into the PDF Snippet from FOP 0.20.5: 2 0 obj /Type /Catalog /Pages 1 0 R /Names /Dests /Names [ (page1) [ 6 0 R /XYZ -5.0 365.0 null ] (page2) [ 8 0 R /XYZ -5.0 365.0 null ] ] endobj Snippets from FOP Trunk before my modifications: 16 0 obj /Limits [(page1) (page1)] /Names [(page1) 17 0 R] endobj 18 0 obj /Limits [(page2) (page2)] /Names [(page2) 19 0 R] endobj 21 0 obj /Limits [(page1) (page2)] /Kids [16 0 R 18 0 R] endobj 22 0 obj /Dests 21 0 R endobj 2 0 obj /Type /Catalog /Pages 1 0 R /Names 22 0 R /Metadata 7 0 R endobj 17 0 obj /Type /Action /S /GoTo /D [8 0 R /XYZ 0.0 360.0 null] endobj 19 0 obj /Type /Action /S /GoTo /D [13 0 R /XYZ 0.0 360.0 null] endobj I don't see anything obviously wrong. But following a suspicion I've done an experiment and flattened the name tree..and the destinations suddenly appear in Adobe Acrobat and my own tests show that destinations seem to work. Snippets from FOP Trunk AFTER my modifications: 19 0 obj /Dests /Names [(page1) 16 0 R (page2) 17 0 R] endobj 2 0 obj /Type /Catalog /Pages 1 0 R /Names 19 0 R /Metadata 7 0 R endobj 16 0 obj /Type /Action /S /GoTo /D [8 0 R /XYZ 0.0 360.0 null] endobj 17 0 obj /Type /Action /S /GoTo /D [13 0 R /XYZ 0.0 360.0 null] endobj I've made quite a few changes in addition to this change: I fixed a few style issues and removed a newly introduced dependency from the PDF library into the area package (DestinationData and PageViewport). So, before I commit this, I'd like to know if, with my modifications, any of you see similar improvements as I do. Thanks. On 11.04.2007 13:29:59 Paul Vinkenoog wrote: Last update for now: - When I link to those destinations as relative URLs, like this: external-destination=nbackup.pdf#nbackup-dochist then sometimes my browser opens the document on the right spot, and sometimes it opens at the top of the file. This is independent of the link, i.e. if a click again on an already visited link, it may turn out right where it first was wrong, or vice versa. The browser always displays the intended location in the URL bar, even if it went top-of-file: file:///F:/FOP/FO-files/nbackup.pdf#nbackup-dochist After putting the files online, everything worked perfectly - for a while. Only after lots and lots of clicking did Firefox seem to get confused and started to land on wrong spots (either top of file, or another existing named destination.) MSIE made a mess of it right from the start. In case anybody wants to play with this, the files are at: http://vinkenoog.nl/test/ The one containing the links is dests.pdf, the target file is nbackup.pdf .fo sources are also there, as well as Jay's test files. Kind regards, Paul Vinkenoog Jeremias Maerki
Re: Change to support named destination and test files
Hugues Leonardi wrote: Hello Paul, Thanks a lot for your help. I will try to build a new fo file as you told. Regards. Hugues Leonardi Paul Vinkenoog wrote: Hello Hugues, All the external links open the second pdf at the first page in acrobat reader. I don't think it is the accent aigu in the id. My xsl-fo and the pdf files are here : http://leohome.free.fr/pmwiki/pmwiki.php?n=PmWiki.Documentation http://leohome.free.fr/pmwiki/pmwiki.php?n=PmWiki.Documentation External links have been written in red in the file named guide-demarrage.xml.pdf. There are in page 27, 31, 37, 40... The reason it doesn't work is that there are no destinations defined in the target document. This doesn't happen automatically; you have to declare them in guide-reference.xml.fo like this: fox:destination internal-destination=GDeLTK/ fox:destination internal-destination=execfeuillestyle/ fox:destination internal-destination=Unites/ fox:destination internal-destination=DocumentAvecPoliceParticuliC(re/ fox:destination internal-destination=ConfigurerFeuilleStyle/ fox:destination internal-destination=liensexternes/ The order is unimportant, and they don't have to be all together either. Just make sure that each fox:destination is the direct child of a fo:block. Also declare this namespace in guide-reference.xml.fo: xmlns:fox=http://xmlgraphics.apache.org/fop/extensions; Then if you rebuild guide-reference, the named destinations will be included in the PDF. There's no need to rebuild guide-demarrage. BTW: your fo:bookmark-trees currently contain this declaration: xmlns:fox=http://xml.apache.org/fop/extensions; This is not necessary, because fo:bookmarks are part of the standard. Also, that URL is outdated, iirc. Hope this helps, Paul Vinkenoog -- View this message in context: http://www.nabble.com/Change-to-support-named-destination-and-test-files-tf3557038.html#a9987401 Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Change to support named destination and test files
Hello Jeremias, First observation: Adobe Acrobat doesn't list any destinations when the PDF is created with FOP Trunk, but it does if you generate the PDF with FOP 0.20.5. So I went into the PDF If I build with the current (unmodified) fop-trunk, Adobe Acrobat 5.0 lists the destinations alright. Which version did you use? Testing your dest.pdf and nbackup.pdf online, I get the same results as before. With Firefox: good most of the time, but sometimes wrong (landing on top of file instead of the page where the target is). With MSIE: wrong most of the time. If I download the files to my computer and test them there, it often goes wrong (note that on my computer, if I click on a URI link in the PDF, MSIE is launched, even though Firefox is my default browser). I can't test your GoToR links locally, because GoToR generation is broken in fop-trunk (they work online though, because they are broken in such a way that they form a correct URL...) So, all in all, after your modifications I get the same results (good and bad) as before. Still I think they're an improvement, because there's less unnecessary indirection. (I also think that where it goes wrong, the browsers are at fault, especially MSIE, and not the destinations code). Regards, Paul Vinkenoog
