Thread: [Jeuclid-devel] Example for a multiline formula available?
Brought to you by:
maxberger
From: Axel <ax...@gm...> - 2007-05-16 17:53:49
|
Hello I would like to know, if it's possible to render a formula on multiple lines. I.e. the maximum width of the output area is defined in pixel and the formula continues on the next line if its greater than this pixel size. -- Axel Kramer WikiBlog: http://www.groovy-news.org/e/page/axelclk |
From: Max B. <ma...@be...> - 2007-05-16 20:48:19
Attachments:
PGP.sig
|
Dear Axel, at this time the only workaround is to use table and to do manual layouting. I have just added linebreaking to the roadmap, as it came up in another email this morning. I would love to see a full line- breaking algorithm, but this would need a few changes to the current code. Of course, if you want to volunteer I can give you help getting started :) Max Berger e-mail: ma...@be... -- PGP/GnuPG ID: E81592BC Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC For information about me or my projects please see http:// max.berger.name Am 16.05.2007 um 19:53 schrieb Axel: > Hello > > I would like to know, if it's possible to render a formula on > multiple lines. > I.e. the maximum width of the output area is defined in pixel and the > formula continues on the next line if its greater than this pixel > size. > > -- > Axel Kramer > WikiBlog: http://www.groovy-news.org/e/page/axelclk > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jeuclid-devel mailing list > Jeu...@li... > https://lists.sourceforge.net/lists/listinfo/jeuclid-devel |
From: Jeremias M. <de...@je...> - 2007-05-16 21:10:47
|
<delurking/> :-) When you guys implement line-breaking support, there are a couple of things WRT XSL-FO/FOP that are worth mentioning: - the current MathML extension in FOP (based on JEuclid 1.0) is implemented as an fo:instream-foreign-object. This formatting object produc= es only one rectangle (more precisely one viewport area and one reference area). In order to support line-breaking inside FOP, this FO couldn't be used. Instead, an extension element would have to be implemented that behaves much like an fo:inline which can produce multiple areas. - JEuclid shouldn't just try to do the line-breaking itself (at least in the FOP case). It should rather be able to just communicate to FOP all the possible breaking points and the painter should then be able to act on the break decision by FOP. Details upon request. As a general remark: fo:instream-foreign-object in FOP currently can't communicate baseline information. That will be one of the things that need to be improved. Happy to see JEuclid so active again. Good luck, guys. On 16.05.2007 22:48:03 Max Berger wrote: > Dear Axel, >=20 > at this time the only workaround is to use table and to do manual =20 > layouting. I have just added linebreaking to the roadmap, as it came =20 > up in another email this morning. I would love to see a full line-=20 > breaking algorithm, but this would need a few changes to the current =20 > code. Of course, if you want to volunteer I can give you help getting =20 > started :) >=20 > Max Berger > e-mail: ma...@be... >=20 > -- > PGP/GnuPG ID: E81592BC Print: F489F8759D4132923EC4 =20 > BC7E072AB73AE81592BC > For information about me or my projects please see http://=20 > max.berger.name >=20 >=20 > Am 16.05.2007 um 19:53 schrieb Axel: >=20 > > Hello > > > > I would like to know, if it's possible to render a formula on =20 > > multiple lines. > > I.e. the maximum width of the output area is defined in pixel and the > > formula continues on the next line if its greater than this pixel > > size. > > > > --=20 > > Axel Kramer > > WikiBlog: http://www.groovy-news.org/e/page/axelclk Jeremias Maerki |
From: Max B. <ma...@be...> - 2007-05-16 21:50:58
Attachments:
PGP.sig
|
Dear Jeremias, thanks for the complement. As you can see my work on on FOP has lead me to start working on JEuclid. Am 16.05.2007 um 23:11 schrieb Jeremias Maerki: > - the current MathML extension in FOP (based on JEuclid 1.0) is > implemented as an fo:instream-foreign-object. This formatting > object produces > only one rectangle (more precisely one viewport area and one reference > area). In order to support line-breaking inside FOP, this FO > couldn't be > used. Instead, an extension element would have to be implemented that > behaves much like an fo:inline which can produce multiple areas. The real problem is that JEuclid's rendering is currently based on rectangles within rectangles, and has no "proper" support for elements on a string, as would be required to do proper linebreaking. This would need to be changed in any case. > - JEuclid shouldn't just try to do the line-breaking itself (at > least in > the FOP case). It should rather be able to just communicate to FOP all > the possible breaking points and the painter should then be able to > act > on the break decision by FOP. Details upon request. In the case of being embedded, it would have to communicate that information back. In other cases, such as for a stand-alone formula or for displaying in the MathViewer, the linerbreaking will have to be done within JEuclid. But it is good to keep in mind that the linebreaking should be deferrable. > As a general remark: fo:instream-foreign-object in FOP currently can't > communicate baseline information. That will be one of the things that > need to be improved. I know. And this is actually one of the things I was doing to write a FOP patch for soon, but I did not want to announce that before I actually have a good idea. I am also not happy about converting MathML -> SVG first, but this is another issue. FYI: I have "stolen" the JEuclid plugin from the current fop SVN and moved it into the JEuclid codebase, so that I am able to update it without asking :) [1]. It is currently disabled, because your upload request [2] fail through > Happy to see JEuclid so active again. Good luck, guys. > [1] http://jeuclid.svn.sourceforge.net/svnroot/jeuclid/trunk/jeuclid- fop/ [2] http://jira.codehaus.org/browse/MAVENUPLOAD-1517 Max Berger e-mail: ma...@be... -- PGP/GnuPG ID: E81592BC Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC For information about me or my projects please see http:// max.berger.name |
From: Jeremias M. <de...@je...> - 2007-05-17 06:33:01
|
On 16.05.2007 23:50:44 Max Berger wrote: <snip/> > > As a general remark: fo:instream-foreign-object in FOP currently can't > > communicate baseline information. That will be one of the things that > > need to be improved. >=20 > I know. And this is actually one of the things I was doing to write a =20 > FOP patch for soon, but I did not want to announce that before I =20 > actually have a good idea. I am also not happy about converting =20 > MathML -> SVG first, but this is another issue. About that: Take a look at Barcode4J where I optimized the painting for various output formats. Going via SVG is indeed to slowest possible way. An XMLHandler takes care of all that. See BarcodeXMLHandler here: http://barcode4j.cvs.sourceforge.net/barcode4j/barcode4j/src/fop-trunk/java= /org/krysalis/barcode4j/fop/ > FYI: I have "stolen" the JEuclid plugin from the current fop SVN and =20 > moved it into the JEuclid codebase, so that I am able to update it =20 > without asking :) [1]. It is currently disabled, because your upload =20 > request [2] fail through I've seen that. That's fine. But it's a good idea to make a note in the code where you forked it from, just to keep an audit trail. About the Maven artifacts, I'll try to get that done ASAP. > > Happy to see JEuclid so active again. Good luck, guys. > > >=20 > [1] http://jeuclid.svn.sourceforge.net/svnroot/jeuclid/trunk/jeuclid-=20 > fop/ > [2] http://jira.codehaus.org/browse/MAVENUPLOAD-1517 >=20 > Max Berger > e-mail: ma...@be... Jeremias Maerki |
From: Max B. <ma...@be...> - 2007-05-19 15:49:09
Attachments:
PGP.sig
|
Jeremias, I am sorry about your experience with the maven artifacts. Maven is a great build-tool, but the documentation is still far (although they are getting better every week). I can totally relate to your experience, moving JEuclid to maven was very frustrating in the beginning (but eventually paid off). Thank you for the good example code. Using this and the old plugin I was able to update it to work without any svg-conversions in-between. I have also made sure the source codes are proper attributed. The results will be released with the next beta-release of JEuclid, which is due soon. Some open issues (maybe i should send these to the fop-dev list?): - ODF support in external files: I have an idea on how this could be done from looking at the XMLReader code, so I should be able to implement that easily. - Context sensitivity: Right now all formulas are rendered using the default fonts, default colors, default size, etc. It would be nice if this information is somehow available from the surrounding <fo:block> element. (I have no idea where to start looking for this). - For MathML there are two rendering modes: inline and display. Somehow it would be nice to figure out if the MathML is in its own fo:block (and therefore display), or within a text line (and therefore inline). Again, I have no idea where to start looking for this information. Also: It may not even be desirable to autodetect that information. - Baseline offsets - I would love to see JEuclid bundled with the next release of FOP :) Max Berger e-mail: ma...@be... -- PGP/GnuPG ID: E81592BC Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC For information about me or my projects please see http:// max.berger.name Am 17.05.2007 um 08:33 schrieb Jeremias Maerki: > > On 16.05.2007 23:50:44 Max Berger wrote: > <snip/> >>> As a general remark: fo:instream-foreign-object in FOP currently >>> can't >>> communicate baseline information. That will be one of the things >>> that >>> need to be improved. >> >> I know. And this is actually one of the things I was doing to write a >> FOP patch for soon, but I did not want to announce that before I >> actually have a good idea. I am also not happy about converting >> MathML -> SVG first, but this is another issue. > > About that: Take a look at Barcode4J where I optimized the painting > for > various output formats. Going via SVG is indeed to slowest possible > way. > An XMLHandler takes care of all that. See BarcodeXMLHandler here: > http://barcode4j.cvs.sourceforge.net/barcode4j/barcode4j/src/fop- > trunk/java/org/krysalis/barcode4j/fop/ > >> FYI: I have "stolen" the JEuclid plugin from the current fop SVN and >> moved it into the JEuclid codebase, so that I am able to update it >> without asking :) [1]. It is currently disabled, because your upload >> request [2] fail through > > I've seen that. That's fine. But it's a good idea to make a note in > the > code where you forked it from, just to keep an audit trail. > > About the Maven artifacts, I'll try to get that done ASAP. > >>> Happy to see JEuclid so active again. Good luck, guys. >>> >> >> [1] http://jeuclid.svn.sourceforge.net/svnroot/jeuclid/trunk/jeuclid- >> fop/ >> [2] http://jira.codehaus.org/browse/MAVENUPLOAD-1517 >> >> Max Berger >> e-mail: ma...@be... > > > > Jeremias Maerki > > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jeuclid-devel mailing list > Jeu...@li... > https://lists.sourceforge.net/lists/listinfo/jeuclid-devel |
From: Jeremias M. <de...@je...> - 2007-05-20 09:04:12
|
Hi Max On 19.05.2007 17:48:55 Max Berger wrote: > Jeremias, >=20 > I am sorry about your experience with the maven artifacts. Maven is a =20 > great build-tool, but the documentation is still far (although they =20 > are getting better every week). I can totally relate to your =20 > experience, moving JEuclid to maven was very frustrating in the =20 > beginning (but eventually paid off). Maven was built after a good idea. But I love the stability of Ant builts. > Thank you for the good example code. Using this and the old plugin I =20 > was able to update it to work without any svg-conversions in-between. =20 > I have also made sure the source codes are proper attributed. The =20 > results will be released with the next beta-release of JEuclid, which =20 > is due soon. >=20 > Some open issues (maybe i should send these to the fop-dev list?): If you get stuck and I'm not around, yes. > - ODF support in external files: I have an idea on how this could be =20 > done from looking at the XMLReader code, so I should be able to =20 > implement that easily. > > - Context sensitivity: Right now all formulas are rendered using the =20 > default fonts, default colors, default size, etc. It would be nice if =20 > this information is somehow available from the surrounding <fo:block> =20 > element. (I have no idea where to start looking for this). We could capture the CommonFont structure in the bind() method of o.a.f.fo.flow.AbstractGraphics (pList.getFontProps()) and pass that information to extension implementations that want this information. > - For MathML there are two rendering modes: inline and display. =20 > Somehow it would be nice to figure out if the MathML is in its own =20 > fo:block (and therefore display), or within a text line (and =20 > therefore inline). Again, I have no idea where to start looking for =20 > this information. Also: It may not even be desirable to autodetect =20 > that information. As long as fo:external-graphic and fo:instream-foreign-object are used, it's always in a text line even if the graphic is the only element in the text line (technically speaking). Both FOs are inline-level elements. > - Baseline offsets Should be doable. > - I would love to see JEuclid bundled with the next release of FOP :) We're pretty much already decided some time ago, that Barcode4J and JEuclid will be bundled with FOP eventually. For Barcode4J, this will be 2.0 when it's ready. That way, people won't have to do an extra download for useful extra functionality. <snip/> Please note that until October I won't have time to seriously help with any of this. Jeremias Maerki |
From: Max B. <ma...@be...> - 2007-05-31 14:11:07
Attachments:
signature.asc
|
Dear Fop-developers, continuing on the improvements of support for image plugins in Fop (particularly MathML plugin), there are two more things that need to be addressed. I am quoting from a previous mail to jeuclid-devel: Jeremias Maerki schrieb: >> - Context sensitivity: Right now all formulas are rendered using the = >> default fonts, default colors, default size, etc. It would be nice if = =20 >> this information is somehow available from the surrounding <fo:block> = =20 >> element. (I have no idea where to start looking for this). > We could capture the CommonFont structure in the bind() method of > o.a.f.fo.flow.AbstractGraphics (pList.getFontProps()) and pass that > information to extension implementations that want this information. This would be great. Unfortunately I have no idea how it would be done in detail. >> - Baseline offsets > Should be doable. I have found a spot where this information would be placeable: FopImage.ImageInfo. Unfortunately, changing this class could probably mean that all plugins will have to be recompiled. Here's my idea: - add a new attribute baselineOffset, default to 0 AbstractGraphics would provide a hook "getAdditionalAlignmentAdjust", and getAlignmentAdjust would use this value; InstreamForeignObject could then use "getAdditionalAlignmentAdjust", to provide the additional offset needed for inline objects. So would it be feasible to change ImageInfo, possibly introducing an API change? And if so, the current API uses fixed-point sizes only (e.g. all sizes can only be complete pixels). IMO this should be changed to support float or double values, as some vector graphics have a higher resolution.= Comments? mfG Max Berger e-mail: ma...@be... --=20 OpenPG ID: E81592BC Print: F489F8759D4132923EC4 BC7E072AB73AE81592BC For information about me and my work please see http://max.berger.name |