Re: fop-ttfreader - output bounding box information for characters?
Hi Alexey, On 08/01/2013 18:12, Alexey Neyman wrote: Hi Chris, On Tuesday, January 08, 2013 12:10:36 am Chris Bowditch wrote: Sounds like we need a FOP plug-in for pMML2SVG to replace the ageing JEuclid one. Pardon my ignorance, but what is FOP using for the XSL transformation? Is it Xalan-based? In that case, it probably won't be sufficient: pMML2SVG requires XSLT 2.0, which, as far as I understand, is only supported by Saxon. You can use whichever XSLT processor you choose with FOP, as long as you feed FOP with XSL-FO. I know that; you mentioned *plug-in* pMML2SVG - I assumed, plug-in is something to be integrated into FOP - which is why I asked what FOP uses for XSLT. Sorry I choose a poor choice of words. I meant the plug-in could use any XSLT processor it needed to. Would probably mean adding a saxon dependency. Thanks, Chris Regards, Alexey. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop-ttfreader - output bounding box information for characters?
On 08/01/2013 07:52, Alexey Neyman wrote: Hi Chris, Hi Alexey, On Monday, January 07, 2013 11:44:46 AM Chris Bowditch wrote: Patch from pMML2SVG, slightly modified to apply to FOP 1.1 sources, attached. Thanks for the patch. To get this added to the code base please raise an issue in JIRA, add the diff as an attachment and include [PATCH] in the subject line. A committer will then review the patch before applying it. Created an issue: https://issues.apache.org/jira/browse/FOP-2180 Thank you. So, can this patch be reviewed/integrated? That shouldn't be a problem. As I indicated Peter is working in a similar area right now, so I will ask him if he can take a look. I know Peter Hancock is looking into doing something similar as he is working on getting Batik to use FOP configured fonts instead of the system ones. Peter mentioned to me offlist that he was going to need to expose a few extra things in TTFReader to facilitate this, could be you are covering similar ground here. Maybe. Then again, the root of the issue is not Batik - that issue I work around by embedding fonts. It is JEuclid's use of system fonts which is why I am switching to pMML2SVG - which needs bounding box information for glyphs. BTW, another useful feature in pMML2SVG that was not available in JEuclid is that pMML2SVG outputs baseline position information in the generated SVG - so that inline equations can be properly positioned on the line. Sounds like we need a FOP plug-in for pMML2SVG to replace the ageing JEuclid one. Pardon my ignorance, but what is FOP using for the XSL transformation? Is it Xalan-based? In that case, it probably won't be sufficient: pMML2SVG requires XSLT 2.0, which, as far as I understand, is only supported by Saxon. You can use whichever XSLT processor you choose with FOP, as long as you feed FOP with XSL-FO. Thanks, Chris Regards, Alexey. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop-ttfreader - output bounding box information for characters?
Hi Chris, On Tuesday, January 08, 2013 12:10:36 am Chris Bowditch wrote: Sounds like we need a FOP plug-in for pMML2SVG to replace the ageing JEuclid one. Pardon my ignorance, but what is FOP using for the XSL transformation? Is it Xalan-based? In that case, it probably won't be sufficient: pMML2SVG requires XSLT 2.0, which, as far as I understand, is only supported by Saxon. You can use whichever XSLT processor you choose with FOP, as long as you feed FOP with XSL-FO. I know that; you mentioned *plug-in* pMML2SVG - I assumed, plug-in is something to be integrated into FOP - which is why I asked what FOP uses for XSLT. Regards, Alexey. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop-ttfreader - output bounding box information for characters?
Hi Alexey, I am happy to apply the patch and I have done something equivalent to this as part of the the project to configure Batik to use custom fonts. Going forward, we hope to allow Batik to directly use Font provided by FOP when converting SVG to Java2D drawing commands. FOP will render text natively with no need to pre-embed the Font into the SVG. As mentioned this is a fairly involved piece of work that may even lead to a new Font library in XML Graphics, see http://markmail.org/thread/hkclkqaxlfh5wwvu. Thanks, Peter On Tue, Jan 8, 2013 at 8:10 AM, Chris Bowditch bowditch_ch...@hotmail.comwrote: On 08/01/2013 07:52, Alexey Neyman wrote: Hi Chris, Hi Alexey, On Monday, January 07, 2013 11:44:46 AM Chris Bowditch wrote: Patch from pMML2SVG, slightly modified to apply to FOP 1.1 sources, attached. Thanks for the patch. To get this added to the code base please raise an issue in JIRA, add the diff as an attachment and include [PATCH] in the subject line. A committer will then review the patch before applying it. Created an issue: https://issues.apache.org/**jira/browse/FOP-2180https://issues.apache.org/jira/browse/FOP-2180 Thank you. So, can this patch be reviewed/integrated? That shouldn't be a problem. As I indicated Peter is working in a similar area right now, so I will ask him if he can take a look. I know Peter Hancock is looking into doing something similar as he is working on getting Batik to use FOP configured fonts instead of the system ones. Peter mentioned to me offlist that he was going to need to expose a few extra things in TTFReader to facilitate this, could be you are covering similar ground here. Maybe. Then again, the root of the issue is not Batik - that issue I work around by embedding fonts. It is JEuclid's use of system fonts which is why I am switching to pMML2SVG - which needs bounding box information for glyphs. BTW, another useful feature in pMML2SVG that was not available in JEuclid is that pMML2SVG outputs baseline position information in the generated SVG - so that inline equations can be properly positioned on the line. Sounds like we need a FOP plug-in for pMML2SVG to replace the ageing JEuclid one. Pardon my ignorance, but what is FOP using for the XSL transformation? Is it Xalan-based? In that case, it probably won't be sufficient: pMML2SVG requires XSLT 2.0, which, as far as I understand, is only supported by Saxon. You can use whichever XSLT processor you choose with FOP, as long as you feed FOP with XSL-FO. Thanks, Chris Regards, Alexey. --**--**- To unsubscribe, e-mail: fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-help@xmlgraphics.**apache.orgfop-users-h...@xmlgraphics.apache.org
Re: fop-ttfreader - output bounding box information for characters?
Hi Alexey, On 04/01/2013 19:41, Alexey Neyman wrote: snip/ Interesting workaround. We are trying to tackle this issue by providing an alternative implementation of GVTFont in Batik that uses FOP's Font Library to load the font metrics. First, as I was told on the list previously, it is not a small feat and it would take some time before this fix is released. Yes, that is correct. Then, even though it would solve the issue for SVGs, it won't help with font selection for MathML. As I explained below, JEuclid pre-renders the glyphs into paths. That's true. I missed the fact you were working with JEuclid And as far as I can tell, JEuclid project is all but dead: the last non- trivial commit was 16 months ago, and the last release 30 months ago. I don't think it is likely JEuclid will catch up with FOP improvements, even when they're available. I'm subscribed to the JEuclid mailing list and I get the same impression. This does not work well with JEuclid, though. When JEuclid generates SVG from MathML, it performs font rendering - that is, replaces characters by actual paths. And again, it uses system fonts, not the fonts available in FOP - even if running as FOP plugin. To work around this issue for MathML, I am currently switching from JEuclid to pMML2SVG (http://pmml2svg.sourceforge.net). It generates SVGs with text characters, not paths. But in order to do so, it needs font metrics. Unfortunately, font metrics produced by stock FOP TTFReader are not sufficient - this stylesheet also needs bounding box for each glyph. To obtain these, pMML2SVG currently packages an augmented TTFReader Java sources which are to be compiled and used in lieu of the stock one. Given that the patch is very small and as far as I can tell, compatible with current users of font metrics (it just adds 4 attributes to glyph description), is it possible to integrate this support into stock FOP? Patch from pMML2SVG, slightly modified to apply to FOP 1.1 sources, attached. Thanks for the patch. To get this added to the code base please raise an issue in JIRA, add the diff as an attachment and include [PATCH] in the subject line. A committer will then review the patch before applying it. Created an issue: https://issues.apache.org/jira/browse/FOP-2180 Thank you. I know Peter Hancock is looking into doing something similar as he is working on getting Batik to use FOP configured fonts instead of the system ones. Peter mentioned to me offlist that he was going to need to expose a few extra things in TTFReader to facilitate this, could be you are covering similar ground here. Maybe. Then again, the root of the issue is not Batik - that issue I work around by embedding fonts. It is JEuclid's use of system fonts which is why I am switching to pMML2SVG - which needs bounding box information for glyphs. BTW, another useful feature in pMML2SVG that was not available in JEuclid is that pMML2SVG outputs baseline position information in the generated SVG - so that inline equations can be properly positioned on the line. Sounds like we need a FOP plug-in for pMML2SVG to replace the ageing JEuclid one. Thanks, Chris Regards, Alexey. Anyway, please raise the JIRA issue otherwise your patch could get lost. Thanks, Chris Regards, Alexey. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop-ttfreader - output bounding box information for characters?
Hi Chris, On Monday, January 07, 2013 11:44:46 AM Chris Bowditch wrote: Patch from pMML2SVG, slightly modified to apply to FOP 1.1 sources, attached. Thanks for the patch. To get this added to the code base please raise an issue in JIRA, add the diff as an attachment and include [PATCH] in the subject line. A committer will then review the patch before applying it. Created an issue: https://issues.apache.org/jira/browse/FOP-2180 Thank you. So, can this patch be reviewed/integrated? I know Peter Hancock is looking into doing something similar as he is working on getting Batik to use FOP configured fonts instead of the system ones. Peter mentioned to me offlist that he was going to need to expose a few extra things in TTFReader to facilitate this, could be you are covering similar ground here. Maybe. Then again, the root of the issue is not Batik - that issue I work around by embedding fonts. It is JEuclid's use of system fonts which is why I am switching to pMML2SVG - which needs bounding box information for glyphs. BTW, another useful feature in pMML2SVG that was not available in JEuclid is that pMML2SVG outputs baseline position information in the generated SVG - so that inline equations can be properly positioned on the line. Sounds like we need a FOP plug-in for pMML2SVG to replace the ageing JEuclid one. Pardon my ignorance, but what is FOP using for the XSL transformation? Is it Xalan-based? In that case, it probably won't be sufficient: pMML2SVG requires XSLT 2.0, which, as far as I understand, is only supported by Saxon. Regards, Alexey.
Re: fop-ttfreader - output bounding box information for characters?
Hi Alexey, Apologies for the slow reply. I'm just catching up on e-mail after the holidays. On 28/12/2012 05:56, Alexey Neyman wrote: Hi all, As I mentioned in another email, I am trying to constrain FOP to use only local fonts (i.e. ones described in fop.cfg). For SVGs, I have a workaround: - Generate fonts in SVG format using ttf2svg utility from Batik; - Use an XSL stylesheet to embed all the fonts used by an SVG image into the image itself; - Use such preprocessed SVG image as the input to FOP. Interesting workaround. We are trying to tackle this issue by providing an alternative implementation of GVTFont in Batik that uses FOP's Font Library to load the font metrics. This does not work well with JEuclid, though. When JEuclid generates SVG from MathML, it performs font rendering - that is, replaces characters by actual paths. And again, it uses system fonts, not the fonts available in FOP - even if running as FOP plugin. To work around this issue for MathML, I am currently switching from JEuclid to pMML2SVG (http://pmml2svg.sourceforge.net). It generates SVGs with text characters, not paths. But in order to do so, it needs font metrics. Unfortunately, font metrics produced by stock FOP TTFReader are not sufficient - this stylesheet also needs bounding box for each glyph. To obtain these, pMML2SVG currently packages an augmented TTFReader Java sources which are to be compiled and used in lieu of the stock one. Given that the patch is very small and as far as I can tell, compatible with current users of font metrics (it just adds 4 attributes to glyph description), is it possible to integrate this support into stock FOP? Patch from pMML2SVG, slightly modified to apply to FOP 1.1 sources, attached. Thanks for the patch. To get this added to the code base please raise an issue in JIRA, add the diff as an attachment and include [PATCH] in the subject line. A committer will then review the patch before applying it. I know Peter Hancock is looking into doing something similar as he is working on getting Batik to use FOP configured fonts instead of the system ones. Peter mentioned to me offlist that he was going to need to expose a few extra things in TTFReader to facilitate this, could be you are covering similar ground here. Anyway, please raise the JIRA issue otherwise your patch could get lost. Thanks, Chris Regards, Alexey. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop-ttfreader - output bounding box information for characters?
Hi Chris, On Friday, January 04, 2013 06:50:30 am Chris Bowditch wrote: Hi Alexey, Apologies for the slow reply. I'm just catching up on e-mail after the holidays. No problem and Happy New Year! On 28/12/2012 05:56, Alexey Neyman wrote: Hi all, As I mentioned in another email, I am trying to constrain FOP to use only local fonts (i.e. ones described in fop.cfg). For SVGs, I have a workaround: - Generate fonts in SVG format using ttf2svg utility from Batik; - Use an XSL stylesheet to embed all the fonts used by an SVG image into the image itself; - Use such preprocessed SVG image as the input to FOP. Interesting workaround. We are trying to tackle this issue by providing an alternative implementation of GVTFont in Batik that uses FOP's Font Library to load the font metrics. First, as I was told on the list previously, it is not a small feat and it would take some time before this fix is released. Then, even though it would solve the issue for SVGs, it won't help with font selection for MathML. As I explained below, JEuclid pre-renders the glyphs into paths. And as far as I can tell, JEuclid project is all but dead: the last non- trivial commit was 16 months ago, and the last release 30 months ago. I don't think it is likely JEuclid will catch up with FOP improvements, even when they're available. This does not work well with JEuclid, though. When JEuclid generates SVG from MathML, it performs font rendering - that is, replaces characters by actual paths. And again, it uses system fonts, not the fonts available in FOP - even if running as FOP plugin. To work around this issue for MathML, I am currently switching from JEuclid to pMML2SVG (http://pmml2svg.sourceforge.net). It generates SVGs with text characters, not paths. But in order to do so, it needs font metrics. Unfortunately, font metrics produced by stock FOP TTFReader are not sufficient - this stylesheet also needs bounding box for each glyph. To obtain these, pMML2SVG currently packages an augmented TTFReader Java sources which are to be compiled and used in lieu of the stock one. Given that the patch is very small and as far as I can tell, compatible with current users of font metrics (it just adds 4 attributes to glyph description), is it possible to integrate this support into stock FOP? Patch from pMML2SVG, slightly modified to apply to FOP 1.1 sources, attached. Thanks for the patch. To get this added to the code base please raise an issue in JIRA, add the diff as an attachment and include [PATCH] in the subject line. A committer will then review the patch before applying it. Created an issue: https://issues.apache.org/jira/browse/FOP-2180 I know Peter Hancock is looking into doing something similar as he is working on getting Batik to use FOP configured fonts instead of the system ones. Peter mentioned to me offlist that he was going to need to expose a few extra things in TTFReader to facilitate this, could be you are covering similar ground here. Maybe. Then again, the root of the issue is not Batik - that issue I work around by embedding fonts. It is JEuclid's use of system fonts which is why I am switching to pMML2SVG - which needs bounding box information for glyphs. BTW, another useful feature in pMML2SVG that was not available in JEuclid is that pMML2SVG outputs baseline position information in the generated SVG - so that inline equations can be properly positioned on the line. Regards, Alexey. Anyway, please raise the JIRA issue otherwise your patch could get lost. Thanks, Chris Regards, Alexey. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
