Re: [Jeuclid-users] Line Breaking algorithm
Brought to you by:
maxberger
From: Max B. <ma...@be...> - 2009-04-02 14:45:14
|
Jason, Jason Zaugg schrieb: > Our solution for Saxon integration is a Java extension method > (http://www.saxonica.com/documentation/extensibility/functions.html) > which is passed a DOM node with the MathML, and returns a String > containing the SVG. > > This string is used to create a special URL with the scheme 'data', > which is a RenderX XEP specific. The XSL looks like: > > <fo:external-graphic src="{concat('data:image/svg,', > mathml:svg($mathMlNode, 1.0))}"/> > > To turn this into a generally useful component, we would need to expose > the configuration API of JEuclid -- currently this is hard-coded in our > Java extension method. I'm not sure this would be worthwhile. I've done a similar thing for Fop - In this case there are "special" attributes which can be set on the <math> element. They have to conform to the JEuclid namespace, and then they are interpreted as JEuclid configuration settings. Unfortunately this is yet to be documented, but I'll try to do this later and send you a link > Block presentation is sufficient for us, inline presentation would > clearly require some co-operation with the RenderX layout engine. We can > also specify the content width in advance. We generate the MathML > dynamically, so we could also insert line-break hints. So this would be the perfect use-case! > Are you saying the JEuclid integration in FOP already supports line > breaks, or just that it would not require custom integration? We did try > FOP initially, but decided on RenderX. However, it is possible to embed > PDFs into RenderX using <fo:external-graphic>, so we could render the > formulas to PDF using FOP and include them. There is also no line-breaking in FOP. With FOP we can use information from the surrounding context to modify the formula: In your example case you use a specific font for the text, and the same font in the formula - the FOP plugin does that for <instream-foreign-objects> automatically. I just have a personal preference for FOP because it is a free project, in your case it is probably better to stay with your current solution, as it seems to work. You can also try to use JEuclid to convert directly from MathML -> PDF. This may / may not give you better results. > We have run into some more basis problems with the printed output -- the > formulas seem blurred. I suspect this is because the text in the SVG is > converted to paths, rather than being represented as text. Are there any > tricks to acheiving better print output? (I'll email you a sample > document separately.) Yes, this is due to the conversion of fonts -> line graphics. On my printer the formulas look a little bit thicker, but not blurry, and actually look better than the rest of the text :) The main reason for this conversion is that Fonts are handled very differently by different systems - MathML has many dependencies on special fonts and characters, and JEuclid has a smart character-replacement strategy. For this to work, however, it must be ensured that the font information known to JEuclid is EXACTLY the same that is available to the final renderer - and this is where a lot of the existing systems break. Even different versions of the same font may have different characters available on different systems or when loaded through different methods (such as ps-fonts vs. ttf fonts). Especially with the two-step conversion (-> svg, -> pdf), we have two intermediate renderers which again have their own font processing and metrics definition. The only way out of this inconsistency was to let Jeuclid also render the fonts. > After we can sharpen up the print output, we'll decide how to proceed > with the line-breaking. > Regards, > Jason Max -- http://max.berger.name/ OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700 |