DO NOT REPLY [Bug 35948] - pre-patch for FOrayFont adaptation to Fop
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=35948. 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=35948 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #17207|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2006-09-26 13:56 --- Created an attachment (id=18917) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18917action=view) Updated patch for the current trunks of Fop and FOrayFont This is an early patch updating the old one to the trunks of both Fop and FOray. This patch is completely broken! It is mainly provided so that Bertrand can start his work on the OpenType support, basing it on FOrayFont instead of the soon-to-be-removed current font library. Only the PDFRenderer is running (note that I didn't say working :-\ ). All of the other renderers, along with the SVG transcoders currently have compilation errors. So the ant build script cannot be used to create the binary, the compilation directory of Eclipse should rather be used instead. Currently there is a bug where digits are displayed instead of normal text with all fonts but truetype ones. I'm sure this is not a big bug but I haven't found it yet. I'll look at it ASAP. There are a few necessary steps to run the application: * A font-configuration file must be provided; currently its path is hardcoded in org.apache.fop.fo.FOEventHandler.java, line 163 (FOrayFontServer.setup(URL to the config file)) * A sample font-config file is provided with this patch; there are 3 paths to change to adapt it to another system: * the path to the dtd which is to be found in the aXSL codebase; * the xml:base attribute of the root element for access to custom fonts; * the base14-root key which should point to the directory of the FOray installation containing the metrics for the base14 fonts. Note that the ending slashes are important! The font families which may be used are the generic families (serif, sans-serif, monospace), or the names of the fonts configured in the aXSL font-config file. For example, in the provided sample file, there is a font-family entry for the Bitstream Charter font. Only the upright normal-weight variant has been configured, which may be accessed in an fo file like the following: fo:block font-family=BitstreamCharter font-style=normal font-weight=normal Some text displayed with the Bitstream Charter Roman font... /fo:block So the value of the font-family attribute in the fo file should match the value of the name attribute of the font-family element in the config file. The jar file contains additional files: two new source files, the jars for aXSL and FOrayFont (which contain a not yet reported bug fix, so don't use other binaries!), and a sample font-config file. Well, I think those informations should be enough to get started... -- 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 35948] - pre-patch for FOrayFont adaptation to Fop
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=35948. 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=35948 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #17208|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2006-09-26 13:58 --- Created an attachment (id=18918) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18918action=view) Additional files: new source files, FOrayFont binaries, font-config 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 40464] - Improve handling of OpenType fonts
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=40464. 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=40464 --- Additional Comments From [EMAIL PROTECTED] 2006-09-26 14:50 --- See also bug #35948, which aims to replace the FOP font-handling code with FOray's -- 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 35948] - pre-patch for FOrayFont adaptation to Fop
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=35948. 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=35948 --- Additional Comments From [EMAIL PROTECTED] 2006-09-26 15:02 --- I have created a new foray-font branch to work on this -- 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 35948] - pre-patch for FOrayFont adaptation to Fop
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=35948. 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=35948 --- Additional Comments From [EMAIL PROTECTED] 2006-09-26 15:19 --- Some of the files in the patch have svn conflict markers in them, here's the list: $ find src -name *.java | xargs grep -l '' src/java/org/apache/fop/render/java2d/Java2DGraphicsState.java src/java/org/apache/fop/render/java2d/Java2DRenderer.java src/java/org/apache/fop/render/ps/PSRenderer.java src/java/org/apache/fop/render/ps/PSTextPainter.java -- 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 35948] - pre-patch for FOrayFont adaptation to Fop
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=35948. 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=35948 --- Additional Comments From [EMAIL PROTECTED] 2006-09-26 15:56 --- (In reply to comment #9) Some of the files in the patch have svn conflict markers in them, here's the list: $ find src -name *.java | xargs grep -l '' src/java/org/apache/fop/render/java2d/Java2DGraphicsState.java src/java/org/apache/fop/render/java2d/Java2DRenderer.java src/java/org/apache/fop/render/ps/PSRenderer.java src/java/org/apache/fop/render/ps/PSTextPainter.java Yes, this is to remind me that I still have merging conflicts to resolve. Currently those marks just cause even more compilation errors... -- 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: How to use FOP in wysiswyg editor, or how to speed up
This is a very interesting and ambitious project. I would like to see such a project succeed. But WYSIWYG editing is very hard to achieve. That was (and is) the case with TeX, where it was tried, and it is the case with FOP. As Jeremias already answered, FOP is not close to such a goal. We would need a whole lot more developers than we have now, and before that, a good design for this goal. In principle it should be possible to let FOP know which subtree of the FO file has changed, and one could let FOP update that part of the FO tree in memory. It is harder to determine which part of the layout has changed. In addition, FOP has a total fit approach to layout, which is not friendly to a partial update. Currently FOP tries to dispose of elements in memory as soon as possible, in the interest of minimal resource usage. A WYSIWYG approach would require that FOP keeps FO tree, layout elements and perhaps a number of finished pages in memory. Do I remember correctly that EuroMath is developed in Academia? FOP could use a similar sponsorship. Without it, this is far too ambitious for us. Regards, Simon On Mon, Sep 25, 2006 at 09:08:40AM +0200, Jeremias Maerki wrote: On 23.09.2006 23:12:06 Tomá Studva wrote: Hi developers, We are using FOP as rendering engine for FO in wysiwyg xml editor http://sourceforge.net/projects/euromath2. When opening about 40 page fo document, the editation is ugly slow. We can track changes in source document(also in case using XSLT), but there is a principal error, because we don't know how to update the FOP produced trees, so new FOP is created to layout document after change and further render by Draw2d (we implemented some basic renderer composed of Draw2D Figures, which are organized into tree). I' ve also profiled our application on such big document, from typing to update of screen and found out, than FOP consumes 1/3 of processor time, that is too much if we optimize anything but not FOP- it takes on good PC about 10 seconds, so FOP 10/3 = 3sec. So, is there possibility to update the FOP produced trees according to change in XML (to use it in editor manner, not only rendering engine)? No, FOP has not been designed to be used as a backend of a WYSIWYG editor like EuroMath2. That's a new requirement/wish. We'd have to find out if and how FOP can be changed to fulfill it. At any rate it's an expansion of the project scope which could be subject to a project decision depending on how extensive the necessary changes can become. Or if not, is there possibility to recycle FOP PageSequence which haven't changed? Not at the moment, maybe with some hacking. It's not just the page-sequence that would have to be recycled. You'd have to find ways to keep the unchanged page-sequences in memory and that includes not only the FO tree but also the area tree. However, changing a page-sequence in the middle might invalidate later page-sequences. And last, is there option to speed up FOP generally, by lowering output quality or something? Not by lowering the output quality, no. You can help by profiling and optimizing FOP and you can make sure the editor only generates the minimal FO content to produce the right document. Many editor generate much too much (redundant) content not making use of property inheritance. That can have an influence on performance. You're welcome to help us improve FOP to better match the requirements of EuroMath2. I'm pretty sure we currently don't have the resources to help you much in this direction. We can give you pointers and we can help you figure out what needs to be changed. Please note this is my take on the situation and may not reflect the opinion of the whole community. I didn't know of EuroMath2 before your post. If I interpret this correctly it is a content editor rather than an editor to create XSLT stylesheets. I've also taken a peek into your wishlist. I don't think you can currently find any open source FO implementation that is better suited for EuroMath2. Concerning the partial FO rendering possibility: It might be possible to come up with a way to render, say, only a single fo:block-container with relatively little effort. This might have the possibly interesting side-effect that we could write a plug-in for Batik to render FO content within an SVG. :-) Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.eu
