Re: AFP Renderer
On Friday 05 May 2006 00:46, KeithHarris wrote: Oopse, sorry - Fop wasn't complaining about the shared id there - it was b/c I'd got the same chunk in a different part of the fo file. Following the old docs just brings up warnings (WARNING: Unknown formatting object http://org.apache.fop/extensions/afp^include-page-overlay ... and ... SEVERE: No LayoutManager maker for class class org.apache.fop.fo.UnknownXMLObj) and - from poking around inside the afp structured fields - I can't track down the references to the overlays. The new syntax is afp:include-page-overlay name= /. This element must be a direct child of a fo:simple-page-master element. This means all pages generated from that page master will have that overlay. Also occurs to me this is should all be on the Users rather than Dev list - for which, apologies. You are probably right here. Manuel
Re: AFP Renderer
On Saturday 06 May 2006 21:20, Manuel Mall wrote: On Friday 05 May 2006 00:46, KeithHarris wrote: Oopse, sorry - Fop wasn't complaining about the shared id there - it was b/c I'd got the same chunk in a different part of the fo file. Following the old docs just brings up warnings (WARNING: Unknown formatting object http://org.apache.fop/extensions/afp^include-page-overlay ... and ... SEVERE: No LayoutManager maker for class class org.apache.fop.fo.UnknownXMLObj) and - from poking around inside the afp structured fields - I can't track down the references to the overlays. The new syntax is afp:include-page-overlay name= /. This element must be a direct child of a fo:simple-page-master element. This means all pages generated from that page master will have that overlay. I forgot to mention the namespace to use: xmlns:afp=http://xmlgraphics.apache.org/fop/extensions/afp; This is with the most current trunk code. The initial version checked in used http://org.apache.fop/extensions/afp instead. Also occurs to me this is should all be on the Users rather than Dev list - for which, apologies. You are probably right here. Manuel Manuel
Namespaces for fop extensions
I wonder if we should agree on some guidelines for the use of namespaces (namespace prefixes) for extensions. I am thinking along the following lines: The namespace http://xmlgraphics.apache.org/fop/extensions; (common prefix fox) is reserved for generic extensions to FOP supported across all (e.g. if handled by layout) or most renderers. Extensions specific to a particular renderer and / or extensions which constitute a rendering hint (e.g. render this image as a grayscale) should be in a renderer specific namespace. That namespace name is formed by appending the common renderer acronym to the above generic extension namespace, e.g. http://xmlgraphics.apache.org/fop/extensions/pdf or http://xmlgraphics.apache.org/fop/extensions/pcl or http://xmlgraphics.apache.org/fop/extensions/afp. At the same time the usual prefix for those extensions would be just the renderer acronym. Even if the same type of rendering hint can be used by different renderers they still should be in separate namespaces as this allows the user control over behaviour on a per renderer basis without changing the fo file. For example lets assume we want to support image conversion hints which allows tuning of the image output format. Instead of having fo:external-graphic fox:output-conversion=grayscale src=xyz.png / I would recommend to use render specific hints like fo:external-graphic afp:output-conversion=grayscale pcl:output-conversion=bitmap pdf:output-converion=jpeg src=xyz.png /. This may not be a good example but I hope it illustrates what I am trying to achieve. Manuel
DO NOT REPLY [Bug 39501] New: - Inkscape SVG figures with text not displayed in PDF
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=39501. 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=39501 Summary: Inkscape SVG figures with text not displayed in PDF Product: Fop Version: 0.92 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: svg AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Platform: Intel Pentium M, Ubuntu 5.10 Breezy Badger Blackdown Java 2 SDK j2sdk1.4 1.4.2.03-1 FOP 0.92beta inkscape 0.42-1build1ubuntu0.1 docbook-xml 4.4-4 docbook-xsl 1.68.1-0.1ubuntu1 When I include an Inkscape SVG graphice without characters it shows up in the PDF result generated by FOP. When I add a character object to the same SVG graphic and try including it, it doesn't show up in the PDF. -- 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 39501] - Inkscape SVG figures with text not displayed in PDF
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=39501. 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=39501 --- Additional Comments From [EMAIL PROTECTED] 2006-05-06 18:16 --- Created an attachment (id=18226) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18226action=view) Test case for the bug To reproduce the bug: - unpack the zip file while preserving the directories - run FOP on the simple_article/simple_article.fo file which includes the two SVG graphics: simple_article/images/simple_figure.svg simple_article/images/simple_figure_with_text.svg - in the final PDF result there will be only one figure (the one resulting from the simple_figure.svg file) Other files in this zip file is the DocBook XML source that the .fo has been generated from, and a PDF file generated from the .fo by my FOP 0.92beta installation. -- 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.
Re: Namespaces for fop extensions
On Sat, May 06, 2006 at 11:31:38PM +0800, Manuel Mall wrote: I wonder if we should agree on some guidelines for the use of namespaces (namespace prefixes) for extensions. I am thinking along the following lines: The namespace http://xmlgraphics.apache.org/fop/extensions; (common prefix fox) is reserved for generic extensions to FOP supported across all (e.g. if handled by layout) or most renderers. Extensions specific to a particular renderer and / or extensions which constitute a rendering hint (e.g. render this image as a grayscale) should be in a renderer specific namespace. That namespace name is formed by appending the common renderer acronym to the above generic extension namespace, e.g. http://xmlgraphics.apache.org/fop/extensions/pdf or http://xmlgraphics.apache.org/fop/extensions/pcl or http://xmlgraphics.apache.org/fop/extensions/afp. At the same time the usual prefix for those extensions would be just the renderer acronym. This sounds fine to me. Even if the same type of rendering hint can be used by different renderers they still should be in separate namespaces as this allows the user control over behaviour on a per renderer basis without changing the fo file. For example lets assume we want to support image conversion hints which allows tuning of the image output format. Instead of having fo:external-graphic fox:output-conversion=grayscale src=xyz.png / I would recommend to use render specific hints like fo:external-graphic afp:output-conversion=grayscale pcl:output-conversion=bitmap pdf:output-converion=jpeg src=xyz.png /. This may not be a good example but I hope it illustrates what I am trying to achieve. I see what you are trying to achieve. Wouldn't users find this overdone, and wonder why they cannot do with a single hint for all renderers? Or would a single hint just not work? Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
Any ideas on Bug 39443? a block over multi pages
Dear FOP-dev group. Firstly would just like to say that the current work being done on FOP is fantastic. I've been able to use it in all manor of places from help guides to dynamic content creation using Cocoon. :) Re: http://issues.apache.org/bugzilla/show_bug.cgi?id=39443 I've done some more testing and the results seem to lean towards ( I suspect) the page layout engine. Different renderers like print, TIFF and SVG are showing the same problem as stated in the report. Could the problem be that when a fo:block is set to span='all' and the block flows over to the next page its span=all attribute setting is lost? Its holds the width correctly (span all width) but the columns are reset back to the default page layout. It happens when 2,3,4,etc columns are set. A workaround, I made each original row into a single table, so that the FO was just a table after table in the same block. It still had issues like above. I then put each table in to its own span all block interleaved with a fo:block#x200b/fo:block , a zero width space. This produced the results I needed. Haven't tested what would happen if a single row spanned 2 or more pages. Does this make sense? Is this a bug like I thought? Regards Adam
