Re: svn commit: r349740 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/pagination/Region.java
Jeremias Maerki wrote: On 09.12.2005 14:42:45 Luca Furini wrote: Relaxed validation for border and padding on region-*. I see that, at the moment, with relaxed validation FOP does no more stops with an error if a region has borders / padding, but anyway the borders and padding are not painted (and even taken into account). I was wondering whether this is supposed to be the final behaviour of FOP, or it's just an intermediate step: in other words, if no one is already working on this, could I have a look at the code and try to add borders and padding to the region areas, or such a change would be vetoed? borders and padding on regions are a good thing IMO, and would not be veto'd by me anyway ;) I'm not sure which, but at least one of the commercial implementations allows borders and padding on region-*. It's ok from my side if you want to do that but it should only work if relaxed validation is active. And please don't forget the test case if you implement the new feature. RenderX's XEP allows borders and padding on regions but issues a warning when they are used that it is an extension to the spec. This is similar to the behaviour that you are proposing. At the moment, I think the produced output is not what a user would expect ... The goal was to improve interoperability with commercial implementations, for people switching to FOP. Its a good thing IMO. Chris
RTF: Size of images incorrect?
(Mostly for Peter Herweg, I guess) I tried to implement SVG support for RTF output by converting the SVG images through Batik's JPEGTranscoder to a JPEG. That part was easy and done in 10 minutes. However, I noticed that all images are currently painted much too small in MS Word Viewer 2003 and OpenOffice 2.0. In RTFHandler, the image size is set in points. However, it looks like RtfExternalGraphic just ignores the pt at the end of the string. It only looks for percentages. Otherwise, it calculates with twips internally (1 twip = 1/20 pt). IMO, picscalex and picscaley should always be 100 and picwgoal and pichgoal should be set to the right dimension in twips, i.e. convert to twips already in the RTFHandler to keep the RTF library FOP-independant. Any ideas? Can anybody confirm that I'm not seeing ghosts here? :-) Thanks. Jeremias Maerki
DO NOT REPLY [Bug 37875] New: - table-cell (header) lose line after pagebreak
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=37875. 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=37875 Summary: table-cell (header) lose line after pagebreak Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P5 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Before the pagebreak the header of the second column has two lines, after the pagebreak it also has the same hight but the text of the second line is not visible. The behaviour can easily be avoided by increasing the width of the cell but i think it should work (or not work) equal on both pages. -- 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 37875] - table-cell (header) lose line after pagebreak
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=37875. 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=37875 --- Additional Comments From [EMAIL PROTECTED] 2005-12-12 18:41 --- Created an attachment (id=17202) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17202action=view) corresponding fo-file -- 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 37877] New: - PDF SVG rendering produces bad dimensions
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=37877. 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=37877 Summary: PDF SVG rendering produces bad dimensions Product: Fop Version: 1.0dev Platform: All URL: http://pingu.ii.uj.edu.pl/~ono/download/fop-0.90-trunk- svg-bug/ OS/Version: All Status: NEW Severity: regression Priority: P4 Component: svg AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Please look at files at URL. At Batik viewer they look fine. But once PDF is generated using FOP dimensions of those files get crazy. Those files are clipped (sample1) or stretched by fop (sample2, sample3). This is serious bug which makes SVG embedding kind of unusable. -- 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 37877] - PDF SVG rendering produces bad dimensions
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=37877. 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=37877 --- Additional Comments From [EMAIL PROTECTED] 2005-12-12 19:34 --- Created an attachment (id=17204) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17204action=view) Buggy behaviour on SVG of FOP 0.90 TRUNK Those are samplefiles that shows buggy FOP behaviour. -- 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 37879] New: - PDF SVG rendering forces stroking text (config setting broken)
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=37879. 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=37879 Summary: PDF SVG rendering forces stroking text (config setting broken) Product: Fop Version: 1.0dev Platform: All OS/Version: All Status: NEW Severity: regression Priority: P4 Component: svg AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Config setting: renderer mime=image/svg+xml strokeText value=false/ /renderer ... is virtual, since there is no code that uses that. But most regression to FOP 0.20 is that when generating PDF, embeded SVG text is forced to be stoked, and it seems there is no way to avoid it. This bug makes files using SVG images with some text grow a lot. Normally file which should be 300KB is 1MB and 70% of the file are strokes of text from SVG files. There is also bug related to that in src/java/org/apache/fop/svg/PDFBridgeContext.java which may be related. In registerSVGBridges() you check for fontInfo and linkTransform, that are not yet uninitialized while super(...) is executing in constructor... however since this function is called from super (BridgeContext) and it is STATIC.. this CODE will never be called. There is also no code for binding PDFTextPaineter like in 0.20.5. But I tried to bind it to the context in PDFSVGHandler but ended up with PDF with no text on SVG files.. however I must confess this PDF was 70% smaller :) Please FIX it.. this is serious regression comparing to FOP 0.20.5. Thanks. -- 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.
AW: Size of images incorrect?
Yes, you are right. I'm quite surprised by myself. I will try to fix this the next few days. But while playing with the rtf code i noticed following behaviour (Word2000 SP3): If i write \picscalex75 \picscaley75 \picwgoal1500 \pichgoal900 i get an image width of about 2cm in Word2000 (as expected), but when i write \picscalex100 \picscaley100 \picwgoal1125 \pichgoal675 it's larger. Can anybody explain this? Kind regards, Peter Herweg -Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Jeremias Maerki Gesendet: Montag, 12. Dezember 2005 17:51 An: fop-dev@xmlgraphics.apache.org Betreff: RTF: Size of images incorrect? (Mostly for Peter Herweg, I guess) I tried to implement SVG support for RTF output by converting the SVG images through Batik's JPEGTranscoder to a JPEG. That part was easy and done in 10 minutes. However, I noticed that all images are currently painted much too small in MS Word Viewer 2003 and OpenOffice 2.0. In RTFHandler, the image size is set in points. However, it looks like RtfExternalGraphic just ignores the pt at the end of the string. It only looks for percentages. Otherwise, it calculates with twips internally (1 twip = 1/20 pt). IMO, picscalex and picscaley should always be 100 and picwgoal and pichgoal should be set to the right dimension in twips, i.e. convert to twips already in the RTFHandler to keep the RTF library FOP-independant. Any ideas? Can anybody confirm that I'm not seeing ghosts here? :-) Thanks. Jeremias Maerki
DO NOT REPLY [Bug 37877] - PDF SVG rendering produces bad dimensions
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=37877. 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=37877 --- Additional Comments From [EMAIL PROTECTED] 2005-12-12 20:12 --- Created an attachment (id=17205) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17205action=view) Result using the most recent revision Are you using the binary distribution, or did you check out the source and build yourself? The two last pictures don't seem to get stretched when I run this FO through FOP (revision 356327). Take a look at the sample in attach (don't mind the #'s for the missing glyphs). Is this more like it? -- 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.
FOrayFont patch almost ready
Team, I've just posted an updated pre-patch of my FOray adaptation work. I put it as a pre-patch because the junit tests don't run well anymore (about 75 errors with junit-layout-standard). However, the pdf output looks right on the few tests I have run. The weird thing is that the XML renderer doesn't seem to get the same values for the area tree elements as the PDF renderer. For now I'm unable to find what's wrong. Perhaps that those who have a better knowledge of the layout part or of the test system will be able to give some hints? I'm going on searching but I think you can start looking at my modifications right now. I hope to find the problem soon. Normally the pdf, ps and AWT outputs should work well. The default font-config file may require some adaptation, especially for the AWT output. You can find informations in [1] and by me. Please don't hesitate to tell me if I've done things wrong or to ask any questions. Thanks, Vincent [1] http://www.axsl.org/font/configure.html
Re: problem in RTFHandler.java
Sorry. I'm accumulating a lot of changes here, some of which are not ready to be committed, yet. Fixed. On 12.12.2005 22:29:01 Andreas L Delmelle wrote: On Dec 12, 2005, at 22:21, Simon Pepping wrote: The method FONode.decorateWithContextInfo(String, ExternalGraphic) is not known in my copy: +log.warn(FONode.decorateWithContextInfo( +Image could not be embedded: + url, eg)); Confirmed. Same here. Cheers, Andreas Jeremias Maerki
Re: FOrayFont patch almost ready
Uhm, cool but where did you post your pre-patch? :-) On 12.12.2005 22:44:04 Vincent Hennebert wrote: Team, I've just posted an updated pre-patch of my FOray adaptation work. I put it as a pre-patch because the junit tests don't run well anymore (about 75 errors with junit-layout-standard). However, the pdf output looks right on the few tests I have run. The weird thing is that the XML renderer doesn't seem to get the same values for the area tree elements as the PDF renderer. For now I'm unable to find what's wrong. Perhaps that those who have a better knowledge of the layout part or of the test system will be able to give some hints? I'm going on searching but I think you can start looking at my modifications right now. I hope to find the problem soon. Normally the pdf, ps and AWT outputs should work well. The default font-config file may require some adaptation, especially for the AWT output. You can find informations in [1] and by me. Please don't hesitate to tell me if I've done things wrong or to ask any questions. Thanks, Vincent [1] http://www.axsl.org/font/configure.html Jeremias Maerki
DO NOT REPLY [Bug 35749] - fo wrapper/basic-link combination doesn't work
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=35749. 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=35749 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |fop- ||[EMAIL PROTECTED] Status|ASSIGNED|NEW --- Additional Comments From [EMAIL PROTECTED] 2005-12-13 08:50 --- The problem in the new example is that the empty inline does not generate any areas. The IDs are registered in the addAreas() method of InlineLayoutManager. Because there is no content this method currently doesn't get called and therefore, the ID is not found. The problem is similar to the other FOs where currently no IDs are supported. We will need to find a way to still register the IDs even if there is no content or no direct relationship of the ID to generating an area. Reassigning to fop-dev as this is low priority for me and I need to concentrate on other things at the moment. Sorry. -- 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.
