DO NOT REPLY [Bug 13450] New: - FOP0.20.4 embedded rendering throws exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13450. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13450 FOP0.20.4 embedded rendering throws exception Summary: FOP0.20.4 embedded rendering throws exception Product: Fop Version: 0.20.4 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Since having changed to fop 0.20.4 version the embedded rendering of from BATIK generated SVG does not work anymore. The following Error is produced: - INFO] building formatting object tree [INFO] [1] [ERROR] svg graphic could not be built: null java.lang.NullPointerException at java.util.Hashtable.get(Hashtable.java:320) at java.net.URL.getURLStreamHandler(URL.java:884) at java.net.URL.init(URL.java:305) at java.net.URL.init(URL.java:224) at java.net.URL.init(URL.java:243) at org.apache.batik.util.ParsedURLData.buildURL(Unknown Source) at org.apache.batik.util.ParsedURLData.openStreamInternal(Unknown Source) at org.apache.batik.util.ParsedURLData.openStream(Unknown Source) at org.apache.batik.util.ParsedURL.openStream(Unknown Source) at org.apache.batik.dom.svg.SAXSVGDocumentFactory.createDocument (Unknown Source) at org.apache.batik.bridge.DocumentLoader.loadDocument(Unknown Source) at org.apache.batik.bridge.URIResolver.getNode(Unknown Source) at org.apache.batik.bridge.URIResolver.getElement(Unknown Source) at org.apache.batik.bridge.BridgeContext.getReferencedElement(Unknown Source) at org.apache.batik.bridge.CSSUtilities.convertClipPath(Unknown Source) at org.apache.batik.bridge.AbstractGraphicsNodeBridge.buildGraphicsNode (Unknown Source) at org.apache.batik.bridge.SVGShapeElementBridge.buildGraphicsNode (Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source) at org.apache.batik.bridge.GVTBuilder.build(Unknown Source) at org.apache.fop.render.pdf.PDFRenderer.renderSVGDocument(Unknown Source) at org.apache.fop.render.pdf.PDFRenderer.renderSVGArea(Unknown Source) at org.apache.fop.svg.SVGArea.render(Unknown Source) at org.apache.fop.render.pdf.PDFRenderer.renderForeignObjectArea (Unknown Source) at org.apache.fop.layout.inline.ForeignObjectArea.render(Unknown Source) at org.apache.fop.render.AbstractRenderer.renderLineArea(Unknown Source) at org.apache.fop.layout.LineArea.render(Unknown Source) at org.apache.fop.render.AbstractRenderer.renderBlockArea(Unknown Source) at org.apache.fop.layout.BlockArea.render(Unknown Source) at org.apache.fop.render.AbstractRenderer.renderBlockArea(Unknown Source) at org.apache.fop.layout.BlockArea.render(Unknown Source) at org.apache.fop.render.AbstractRenderer.renderAreaContainer(Unknown Source) at org.apache.fop.layout.ColumnArea.render(Unknown Source) at org.apache.fop.render.AbstractRenderer.renderSpanArea(Unknown Source) at org.apache.fop.layout.SpanArea.render(Unknown Source) at org.apache.fop.render.AbstractRenderer.renderBodyAreaContainer (Unknown Source) at org.apache.fop.render.pdf.PDFRenderer.renderPage(Unknown Source) at org.apache.fop.render.pdf.PDFRenderer.render(Unknown Source) at org.apache.fop.apps.StreamRenderer.queuePage(Unknown Source) at org.apache.fop.layout.AreaTree.addPage(Unknown Source) at org.apache.fop.fo.pagination.PageSequence.format(Unknown Source) at org.apache.fop.apps.StreamRenderer.render(Unknown Source) at org.apache.fop.fo.FOTreeBuilder.endElement(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.endElement (AbstractSAXParser.java:559) at org.apache.xerces.impl.XMLNamespaceBinder.handleEndElement (XMLNamespaceBinder.java:853) at org.apache.xerces.impl.XMLNamespaceBinder.endElement (XMLNamespaceBinder.java:643) at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement (XMLDTDValidator.java:2978) at
DO NOT REPLY [Bug 12630] - resizing images
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12630. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12630 resizing images --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 10:32 --- Gif anf JPEG are scaled correctly, but with SVG the image is contained in an area of the requested size, but the SVG content is not scaled. I.e. fo:external-graphic src=file:boxes.svg/ fo:external-graphic src=file:boxes.svg width=2in / fo:external-graphic src=file:boxes.svg width=3in / fo:external-graphic src=file:boxes.svg width=50mm / fo:external-graphic src=file:../../graphics/xml_feather_transparent.gif/ fo:external-graphic src=file:../../graphics/xml_feather_transparent.gif width=2in / fo:external-graphic src=file:../../graphics/xml_feather_transparent.gif width=3in / fo:external-graphic src=file:../../graphics/xml_feather_transparent.gif width=50mm / The GIFs are all scaled correctly, but the SVG all apper the same size, with lots of white space around them. This was tested by adding these lines to the svg/external.fo example - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13451] New: - rendering of SVG with strokeSVGText = false causes exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13451. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13451 rendering of SVG with strokeSVGText = false causes exception Summary: rendering of SVG with strokeSVGText = false causes exception Product: Fop Version: 0.20.4 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When rendering FO with embedded SVG Graphic and strokeSVGText = false following exception is produced: [INFO] [2] [ERROR] svg graphic could not be rendered: null java.lang.NullPointerException at org.apache.fop.svg.PDFTextPainter.paint(Unknown Source) at org.apache.batik.gvt.TextNode.primitivePaint(Unknown Source) at org.apache.batik.gvt.AbstractGraphicsNode.paint(Unknown Source) at org.apache.batik.gvt.TextNode.paint(Unknown Source) at org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint(Unknown Source) at org.apache.batik.gvt.AbstractGraphicsNode.paint(Unknown Source) at org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint(Unknown Source) at org.apache.batik.gvt.AbstractGraphicsNode.paint(Unknown Source) at org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint(Unknown Source) at org.apache.batik.gvt.CanvasGraphicsNode.primitivePaint(Unknown Source) at org.apache.batik.gvt.AbstractGraphicsNode.paint(Unknown Source) at org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint(Unknown Source) at org.apache.batik.gvt.AbstractGraphicsNode.paint(Unknown Source) at org.apache.fop.render.pdf.PDFRenderer.renderSVGDocument(Unknown Source) at org.apache.fop.render.pdf.PDFRenderer.renderSVGArea(Unknown Source) at org.apache.fop.svg.SVGArea.render(Unknown Source) at org.apache.fop.render.pdf.PDFRenderer.renderForeignObjectArea (Unknown Source) at org.apache.fop.layout.inline.ForeignObjectArea.render(Unknown Source) at org.apache.fop.render.AbstractRenderer.renderLineArea(Unknown Source) at org.apache.fop.layout.LineArea.render(Unknown Source) at org.apache.fop.render.AbstractRenderer.renderBlockArea(Unknown Source) at org.apache.fop.layout.BlockArea.render(Unknown Source) at org.apache.fop.render.AbstractRenderer.renderBlockArea(Unknown Source) at org.apache.fop.layout.BlockArea.render(Unknown Source) at org.apache.fop.render.AbstractRenderer.renderAreaContainer(Unknown Source) at org.apache.fop.layout.ColumnArea.render(Unknown Source) at org.apache.fop.render.AbstractRenderer.renderSpanArea(Unknown Source) at org.apache.fop.layout.SpanArea.render(Unknown Source) at org.apache.fop.render.AbstractRenderer.renderBodyAreaContainer (Unknown Source) at org.apache.fop.render.pdf.PDFRenderer.renderPage(Unknown Source) at org.apache.fop.render.pdf.PDFRenderer.render(Unknown Source) at org.apache.fop.apps.StreamRenderer.queuePage(Unknown Source) at org.apache.fop.layout.AreaTree.addPage(Unknown Source) at org.apache.fop.fo.pagination.PageSequence.format(Unknown Source) at org.apache.fop.apps.StreamRenderer.render(Unknown Source) at org.apache.fop.fo.FOTreeBuilder.endElement(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.endElement (AbstractSAXParser.java:559) at org.apache.xerces.impl.XMLNamespaceBinder.handleEndElement (XMLNamespaceBinder.java:853) at org.apache.xerces.impl.XMLNamespaceBinder.endElement (XMLNamespaceBinder.java:643) at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement (XMLDTDValidator.java:2978) at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement (XMLDTDValidator.java:918) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.handleEndElement (XMLDocumentFragmentScannerImpl.java:1145) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement (XMLDocumentFragmentScannerImpl.java:988) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher. dispatch(XMLDocumentFragmentScannerImpl.java:1446) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument (XMLDocumentFragmentScannerImpl.java:333) at org.apache.xerces.parsers.StandardParserConfiguration.parse (StandardParserConfiguration.java:529) at org.apache.xerces.parsers.StandardParserConfiguration.parse (StandardParserConfiguration.java:585) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:147)
AW: BARCODE
Why not a fast, flexible and reliable solution? 3 things are needed: o Java routines to calculate barcode rectangles and label areas depending from barcode type and its parameters. Possibly such routines are freely available. Otherwise: give me the specs, I will write the code (the nowadays popular datamatrix will be harder) and somebody has to run scan tests. o Java code to render the rectangles: very easy in PDF o Handy XSL:FO Input. My experimental hack below is functionally OK allowing barcode type selection with appropriate parameters. The renderer extensions is quite easy and elegant. Hansuli Anderegg __ Barcode Input fo:block width=0pt height=0pt fo:instream-foreign-object width=0pt height=0pt svg:svg width=0 height=0 svg:desccontent: bar3of9, D014679, 60.0, 600.0, 18.0, 1.44, 2.25/svg:desc ||| | | | | ||| | | | + ration narrow/wide ||| | | + module width ||| | + height ||| + y position ||+ x position |+ barcode data + barcode type /svg:svg /fo:instream-foreign-object /fo:block - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13450] - FOP0.20.4 embedded rendering throws exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13450. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13450 FOP0.20.4 embedded rendering throws exception --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 12:10 --- This is probably the same problem as described in the two threads below: http://koala.ilog.fr/batik/mlists/batik-users/archives/msg01945.html http://koala.ilog.fr/batik/mlists/batik-users/archives/msg02019.html It looks like we have to include an upgraded Batik for 0.20.5. Eveline, could you please attach the FO file you've already sent me to this bugreport, so the person who will handle this bug will be able to test? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Extensions to make PPoint like presentations
Hello, here is an interesting link: http://www-sp.iti.informatik.tu-darmstadt.de/software/ppower4/ It seems that the pdf format allows also to create some interesting effects usefull when doing presentations. Take a look at the examples in that link. It would be interesting to add the capacity of creating such effects to FOP, what do you think? Roland
Progress report on FOP 1.0 ?
When last updated, on the 10th of June 2002, it was stated that the development effort is roughly 35% towards a developers release. May I ask, four months later, if the baby is growing well ? P. Andries - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: New Developer Suggestion
Me: So what I was hoping for is a suggestion for something that I can work on that might be useful, but not critical to any immediate plans, ideally something that overlaps little with currently active portions of the project. There were no replies yesterday. Does anyone have a suggestion about something I could look at fixing / enhancing which is not mission-critical, but which might give me a chance to look at a fair bit of the code? Thanks, -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: New Developer Suggestion
Hi Scott, On Wednesday 09 October 2002 16:20, Sauyet, Scott (OTS-HAR) wrote: Does anyone have a suggestion about something I could look at fixing / enhancing which is not mission-critical, but which might give me a chance to look at a fair bit of the code? The integration of jfor (www.jfor.org) as a structure renderer for RTF documents is still waiting for someone to jump in. If you have good java skills and want to tackle this one we can certainly help you find your way. But note that this part of FOP is not at all related to PDF layout, fonts, etc., it's a fairly different way of rendering documents. -- Bertrand Delacrétaz (codeconsult.ch, jfor.org) buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding. disclaimer: eternity is very long. mostly towards the end. get ready. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Bug handling survey - Tree based models
Hello FOP contributors, I am conducting a survey about the way bugs are handled in open source software projects. The survey includes questions that can be answered by developers,testers, bug fixers, project managers, and owners of defect databases. It is only and only for research purposes and it is very easy to fill out. It consists of three short sections which can be completed at once or in different sessions. Please fill it out if you haven't done yet. You will find the questions interesting since there is a reason behind each one one of them. They will make you think about how things work (or could work)in your project. The survey can be found in the address: http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html The data in the bug databases can be used to identify the high risk areas in the software development. One of the ways of doing it is constructing tree-based models, which could be very useful in open source projects. If you would like to read about it, I prepared a web page for you: http://www.seas.smu.edu/~gkoru/surveys/tbdm1.html Please accept my apologies if you receive duplicates of this e-mail. This is a survey, which will give useful results for all of us. I will try to prepare and make some preliminary results on-line within the next two weeks. Since this is a survey, covering many important open source projects, it will be interesting for everybody to see what kind of quality assurance work is going on in the other projects. As always, we are very dedicated to this research. Please contact me for any question you might have. Thank you, A. Gunes Koru http://www.engr.smu.edu/~gkoru - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
FO WYSIWYG-Editor Project launched @ Sourceforge
Hi, I wanted to let you know that I successfully registered a FO-editor-project at Sourceforge yesterday. I'm _not_ trying to compete with Paul's ([EMAIL PROTECTED]). I just thought there might have been some problems with his registration. My request was approved within 4 hours. I have already started to experiment and written some very basic classes (though not uploaded, yet). I'd be glad to see you join. The project is called prettypress. Best regards, Marc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4002] - TTFReader unable to handle 3 of 9 Barcode font
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4002. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4002 TTFReader unable to handle 3 of 9 Barcode font --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 15:18 --- Hi there, I'm having the same problem. Someone is disussing this problem in the following newsgroup: http://marc.theaimsgroup.com/?l=fop-devm=103098230522738w=2 It seems that one way to solve this problem for several .ttf files is to convert it in a .ttx file and then back again to .ttf through FootTools (Open Source software that you can download from http://sourceforge.net/projects/fonttools/ ). They say that by these transformations, some .ttf that previuosly had trouble to be used with TTFReader, has begun to work. I tried the same with the 3of9.ttf file, but the process to re-convert the .ttx file in .ttf file does NOT work. It stops giving out this message: C:\Programmi\TTXttx -s C:\Programmi\TTX\MieiFiles\3OF9Gio.ttx C:\Programmi\TTX\ MieiFiles\3OF9Gio.ttf Compiling C:\Programmi\TTX\MieiFiles\3OF9.ttx to C:\Programmi\TTX\MieiFile s\3OF9.ttf... Parsing 'GlyphOrder' table... Parsing 'OS/2' table... Parsing 'PCLT' table... Parsing 'cmap' table... Parsing 'cvt ' table... Parsing 'fpgm' table... Parsing 'glyf' table... Parsing 'head' table... Traceback (most recent call last): File fontTools\ttx.pyc, line 243, in main File fontTools\ttx.pyc, line 228, in process File fontTools\ttx.pyc, line 163, in ttCompile File fontTools\ttLib\__init__.pyc, line 272, in importXML File fontTools\ttLib\xmlImport.pyc, line 134, in importXML File fontTools\ttLib\xmlImport.pyc, line 24, in parse File fontTools\ttLib\xmlImport.pyc, line 44, in parseFile File fontTools\ttLib\xmlImport.pyc, line 107, in endElementHandler File fontTools\ttLib\tables\_h_e_a_d.pyc, line 77, in fromXML File fontTools\ttLib\tables\_h_e_a_d.pyc, line 121, in parse_date OverflowError: mktime argument out of range (Hit any key to exit) Let me know for any news!!! Cheers! Ale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: fonts
Jeremias Maerki wrote: I'm talking mainly about font metrics at the moment. There are several areas to the whole discussion though: - font metrics (has an effect on the layout/appearance) - available fonts (different font types and sources, different quality of information) - font embedding (how do I get to the physical font and how do I transform it for the target format) - character encodings - speed and memory consumption issues (forgot anything?) That list looks complete to me. Right. What would that class you propose be? I don't think you have to change a lot, just do a refactoring step to streamline the whole stuff. If you like my font manager approach (which handles the different font sources), maybe that's your class to build. It would be rather cool if the font stuff could be moved from the layout and render packages over to the font package so it is pretty isolated. Also makes it easier to work on and to provide a clean solution. I agree with all of that. I intend to leave existing logic alone as much as possible, but to put a layer on top of it, then add the AWT stuff on under that layer (ie. as a sister layer to the existing stuff). I'll probably leave the moving to different packages to someone with commit access, as I don't see how to roll that up into a submittable patch. However, I agree that we should isolate and generalize it as much as possible. Also, I will build any new classes in the fonts package. One last question: you're planning to work on the redesign branch, right? Actually, I was planning on working in the maint branch for a whole bunch of reasons. If you think it is important to work in the trunk, I'll reconsider. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FO WYSIWYG-Editor Project launched @ Sourceforge
I am jumping straight in...let me know how to gt into the project and start contributing -Original Message- From: Marc D. Migge [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 8:10 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: FO WYSIWYG-Editor Project launched @ Sourceforge Hi, I wanted to let you know that I successfully registered a FO-editor-project at Sourceforge yesterday. I'm _not_ trying to compete with Paul's ([EMAIL PROTECTED]). I just thought there might have been some problems with his registration. My request was approved within 4 hours. I have already started to experiment and written some very basic classes (though not uploaded, yet). I'd be glad to see you join. The project is called prettypress. Best regards, Marc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] THIS E-MAIL MESSAGE ALONG WITH ANY ATTACHMENTS IS INTENDED ONLY FOR THE ADDRESSEE and may contain confidential and privileged information. If the reader of this message is not the intended recipient, you are notified that any dissemination, distribution or copy of this communication is strictly Prohibited. If you have received this message by error, please notify us immediately, return the original mail to the sender and delete the message from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Fw: Arabic characters and FOP
I'm willing to help (slowly) implementing the bidi support (contextualisation and bidi algorithms). Is someone else busy doing it ? Is the time ripe to do so ? - Message d'origine - De : [EMAIL PROTECTED] (See attached file: example.fo) (See attached file: fo.gif) hi pat, i am not using any bidi enabled editor, i just typed the fo using text editor [PA] I see, you are typing character references entities. and view it in IE [PA] Well, IE is bidi-enabled ! [PA] I suspect to print it with FO, bidi needs to be implemented in FO. (I'm still a volunteer to do it ;-)) Patrick Andries o - 0 - 0 Tout Unicode en français Nouveaux textes ! http://hapax.iquebec.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FO WYSIWYG-Editor Project launched @ Sourceforge
Mark Malone wrote: where do I sign-up!? People, don't take it wrong, but you know, it's *fop*-dev list actually :) -- Oleg Tkachenko eXperanto team Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FO WYSIWYG-Editor Project launched @ Sourceforge
- Message d'origine - De : Oleg Tkachenko [EMAIL PROTECTED] À : [EMAIL PROTECTED] Envoyé : 9 oct. 2002 12:53 Objet : Re: FO WYSIWYG-Editor Project launched @ Sourceforge Mark Malone wrote: where do I sign-up!? People, don't take it wrong, but you know, it's *fop*-dev list actually :) Well, where should they go ? Thanks. P. Andries - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FO WYSIWYG-Editor Project launched @ Sourceforge
patrick andries wrote: where do I sign-up!? People, don't take it wrong, but you know, it's *fop*-dev list actually :) Well, where should they go ? http://sourceforge.net/projects/prettypress I presume. It's now different project with own maillists etc. -- Oleg Tkachenko eXperanto team Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13464] New: - part of word missing when broken across pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13464. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13464 part of word missing when broken across pages Summary: part of word missing when broken across pages Product: Fop Version: 0.20.4 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Run xml file, xsl file to create pdf. Output is 19 pages. Runs ok however when I look at 1 block of text that breaks across pages I see the following: ...given by the holders of class A --footer-- --page break-- eferred shares... Of course that should say preferred shares. Only seems to happen in the one spot. Should mention that the xml file consists of a wrapper file with calls to external entity files. The xsl file also consists of a wrapper with includes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fw: Arabic characters and FOP
patrick andries wrote: I'm willing to help (slowly) implementing the bidi support (contextualisation and bidi algorithms). Is someone else busy doing it ? Is the time ripe to do so ? Implementation of bidi algorithm itself is not a problem as java has already bidi support since jdk1.3 (it's hidden in 1.3 and revealed in 1.4 in form of java.text.Bidi class). So I believe there are no obstacles for redesigned fop to implement bidi support. PS.Actually it's even feasible to produce hebrew pdf using fop right now (well, under certain circumstances). -- Oleg Tkachenko eXperanto team Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: New Developer Suggestion
Hi Scott Your offer is highly appreciated even if the feedback to your initial mail was a bit sparse. :-) We're all struggling for time to work on FOP and gladly take any helping hand. On 09.10.2002 17:15:21 Sauyet, Scott (OTS-HAR) wrote: = Bertrand Delacretaz [EMAIL PROTECTED] = Scott Sauyet [EMAIL PROTECTED] Does anyone have a suggestion about something I could look at fixing / enhancing which is not mission-critical, but which might give me a chance to look at a fair bit of the code? The integration of jfor (www.jfor.org) as a structure renderer for RTF documents is still waiting for someone to jump in. If you have good java skills and want to tackle this one we can certainly help you find your way. I expect my Java skills are up to the task. This is all J2SE, right? I have no experience with J2ME, and only a little with J2EE. That's fully sufficient. We're only doing J2SE here. I don't really have a sense of the charter of FOP. I know that there is a an AWT Renderer as well as the PDF converter, but is that meant more as a testing system than as something critical to the central project? Or do I misunderstand? So is integrating other renderers something that the group would eventually like to do? FOP already has quite a bunch of renderers: PDF, AWT, PS, MIF, Text etc. PDF is the classic renderer. It has traditionally the best quality. The redesign focuses on PDF at the moment and as soon as the layout is advanced enough we will surely begin to reimplement the other renderers again. AFP and others will also be welcome additions. So, we're not really talking about a testing system. PDF is just the most important format. And AWT output is just another. For me, that would be a real plus, as I'm hoping to eventually work with PDLs for high-volume printers. As FOP is in a redesign phase it would be nice to have help with bringing FOP's layout to the level of the current maintenance branch before implementing more output formats. PDF is the reference and once this works acceptably we can think about reimplementing all other renderers including new ones. Integrating JFOR as suggested by Betrand is also a good idea, because it doesn't depend so much on the layout stuff. Actually, we can't tell you what you should do. If you like to implement a AFP renderer, then do it. Any help is welcome. Look here for todo lists: (Unfortunately we don't have a single todo list ATM) - http://cvs.apache.org/viewcvs.cgi/xml-fop/status.xml - http://xml.apache.org/fop/todo.html - Bugzilla To get familiar with FOP and the new design the following is a good starting point: http://xml.apache.org/fop/design/index.html But note that this part of FOP is not at all related to PDF layout, fonts, etc., it's a fairly different way of rendering documents. As of today, I know nothing about PDF syntax and little about RTF. I figure I'm going to have to learn both. I understand FO fairly well, and I speak Java fairly fluently. What do you think is first priority? So how would we expect this to integrate. What user code would change to generate an RTF document rather than a PDF one? And as to mechanics, what code should I start with? The output format is decided in the org.apache.fop.apps.Driver class ATM. Use that as a starting point. The StructureHandler class is the another important focus point for integrating RTF. You should also search the mailing list archives for the discussion on the JFOR integration. That will explain how this should be done. Good luck diving into FOP. We'll try to support you as best as we can. Fire away with questions as they come up! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Off-Topic Gripe (WAS:RE: New Developer Suggestion)
I think struggling might be understating it, at least for me. Kull Wahad! Why does the work come in faster than time? I think I smell the secret to hyperspace here... -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 2:07 PM To: [EMAIL PROTECTED] Subject: Re: New Developer Suggestion Hi Scott Your offer is highly appreciated even if the feedback to your initial mail was a bit sparse. :-) We're all struggling for time to work on FOP and gladly take any helping hand. On 09.10.2002 17:15:21 Sauyet, Scott (OTS-HAR) wrote: = Bertrand Delacretaz [EMAIL PROTECTED] = Scott Sauyet [EMAIL PROTECTED] Does anyone have a suggestion about something I could look at fixing / enhancing which is not mission-critical, but which might give me a chance to look at a fair bit of the code? The integration of jfor (www.jfor.org) as a structure renderer for RTF documents is still waiting for someone to jump in. If you have good java skills and want to tackle this one we can certainly help you find your way. I expect my Java skills are up to the task. This is all J2SE, right? I have no experience with J2ME, and only a little with J2EE. That's fully sufficient. We're only doing J2SE here. I don't really have a sense of the charter of FOP. I know that there is a an AWT Renderer as well as the PDF converter, but is that meant more as a testing system than as something critical to the central project? Or do I misunderstand? So is integrating other renderers something that the group would eventually like to do? FOP already has quite a bunch of renderers: PDF, AWT, PS, MIF, Text etc. PDF is the classic renderer. It has traditionally the best quality. The redesign focuses on PDF at the moment and as soon as the layout is advanced enough we will surely begin to reimplement the other renderers again. AFP and others will also be welcome additions. So, we're not really talking about a testing system. PDF is just the most important format. And AWT output is just another. For me, that would be a real plus, as I'm hoping to eventually work with PDLs for high-volume printers. As FOP is in a redesign phase it would be nice to have help with bringing FOP's layout to the level of the current maintenance branch before implementing more output formats. PDF is the reference and once this works acceptably we can think about reimplementing all other renderers including new ones. Integrating JFOR as suggested by Betrand is also a good idea, because it doesn't depend so much on the layout stuff. Actually, we can't tell you what you should do. If you like to implement a AFP renderer, then do it. Any help is welcome. Look here for todo lists: (Unfortunately we don't have a single todo list ATM) - http://cvs.apache.org/viewcvs.cgi/xml-fop/status.xml - http://xml.apache.org/fop/todo.html - Bugzilla To get familiar with FOP and the new design the following is a good starting point: http://xml.apache.org/fop/design/index.html But note that this part of FOP is not at all related to PDF layout, fonts, etc., it's a fairly different way of rendering documents. As of today, I know nothing about PDF syntax and little about RTF. I figure I'm going to have to learn both. I understand FO fairly well, and I speak Java fairly fluently. What do you think is first priority? So how would we expect this to integrate. What user code would change to generate an RTF document rather than a PDF one? And as to mechanics, what code should I start with? The output format is decided in the org.apache.fop.apps.Driver class ATM. Use that as a starting point. The StructureHandler class is the another important focus point for integrating RTF. You should also search the mailing list archives for the discussion on the JFOR integration. That will explain how this should be done. Good luck diving into FOP. We'll try to support you as best as we can. Fire away with questions as they come up! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fw: Arabic characters and FOP
Good, no need to help thus. - Message d'origine - De : Oleg Tkachenko [EMAIL PROTECTED] À : [EMAIL PROTECTED] Envoyé : 9 oct. 2002 13:51 Objet : Re: Fw: Arabic characters and FOP patrick andries wrote: I'm willing to help (slowly) implementing the bidi support (contextualisation and bidi algorithms). Is someone else busy doing it ? Is the time ripe to do so ? Implementation of bidi algorithm itself is not a problem as java has already bidi support since jdk1.3 (it's hidden in 1.3 and revealed in 1.4 in form of java.text.Bidi class). So I believe there are no obstacles for redesigned fop to implement bidi support. PS.Actually it's even feasible to produce hebrew pdf using fop right now (well, under certain circumstances). -- Oleg Tkachenko eXperanto team Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fw: Arabic characters and FOP
patrick andries wrote: Good, no need to help thus. I didn't say that! Volunteers are desperately needed, they are blood of fop project, so if you are willing - you are welcome. Look at today's New Developer Suggestion thread, for example. -- Oleg Tkachenko eXperanto team Multiconn International, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fw: Arabic characters and FOP
- Message d'origine - De : Oleg Tkachenko [EMAIL PROTECTED] patrick andries wrote: Good, no need to help thus. I didn't say that! Volunteers are desperately needed, they are blood of fop project, so if you are willing - you are welcome. Look at today's New Developer Suggestion thread, for example. Okay, okay. I will have a look at it. My own strengths are Unicode, i18n (I still believe you must understand what you are doing and test the different scripts even if Java does most of the job) and fonts (OpenType for instance(*)). I would like to help (not alone...) give the best support in this area, but I'm willing to help (slowly) in other areas in the mean time if the new code is not yet ready to add these features. I will have a look at the todo list and the state of the code and come back (privately) when I have some time. Patrick Andries (member of the Canadian character set committee translator for the ISO JT/SC2/GT2) http://hapax.iquebec.com (*) Does anaybody know how glyphs variants and ligatures (see the substitution feature in Opentype) should be selected from fo ? I believe there is currently no such mechanism. Should we wait until another version of XSL-FO? Extensions ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Progress report on FOP 1.0 ?
patrick andries wrote: When last updated, on the 10th of June 2002, it was stated that the development effort is roughly 35% towards a developers release. May I ask, four months later, if the baby is growing well ? Well, some important parts have been done but it is still perhaps 39% or 40%. Whether this is growing well is anyones guess. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fw: Arabic characters and FOP
patrick andries wrote: (*) Does anaybody know how glyphs variants and ligatures (see the substitution feature in Opentype) should be selected from fo ? I believe there is currently no such mechanism. Should we wait until another version of XSL-FO? Extensions ? IIRC the spec mentions it's at the whim of the processor to provide ligatures. There are also various code points assigned to ligatures and presentation forms, for example U+FB01, which could be used in the FO source (at the risk of confusing hyphenation, spell checkers and others). If such characters are mapped to glyphs by a font, FOP can handle them. Also, the discussion whether presentation forms have to be expressed by the characters itself or out of band, for example as fonts, has never ended. XSLFO obviously provides font specification, how presentational forms expressed as Unicode characters have to be handled is not mentioned at all in the spec and presumably left to the processor. It shouldn't be all that much work to provide mappings from presentational forms to canonical code points and hook them into the character lookup: if the lookup for the currently selected fonts fails, the mapping kicks in, perhaps selecting a new first priority font and repeating the lookup with the mapping result. This could also easily map #xFB01; to fi. The other way around (fi - #xFB01;) is much more difficult, because of overlapping mappings needing look-aheads (the ff and ffi ligatures) and irregularities, for example auffinden does not use the ffi ligature. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/render/ps PSRenderer.java
pietsch 2002/10/09 12:30:21
Modified:src/org/apache/fop/render/ps Tag: fop-0_20_2-maintain
PSRenderer.java
Log:
Fixed sloppy passing of StringBuffer which causes problems if
debug information is generated.
PR:13433
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
No revision
No revision
1.15.2.10 +5 -4 xml-fop/src/org/apache/fop/render/ps/PSRenderer.java
Index: PSRenderer.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/render/ps/PSRenderer.java,v
retrieving revision 1.15.2.9
retrieving revision 1.15.2.10
diff -u -r1.15.2.9 -r1.15.2.10
--- PSRenderer.java 12 Aug 2002 17:05:09 - 1.15.2.9
+++ PSRenderer.java 9 Oct 2002 19:30:20 - 1.15.2.10
@@ -724,10 +724,11 @@
if (area.getFontState().getLetterSpacing() 0) {
//float f = area.getFontState().getLetterSpacing() * 1000 /
this.currentFontSize;
float f = area.getFontState().getLetterSpacing();
-psString = (new StringBuffer().append(f).append( 0.0 ().append(sb).
-append() A)).toString();
+psString = (new StringBuffer().append(f).append( 0.0 ()
+ .append(sb.toString()).append() A)).toString();
} else {
-psString = (new StringBuffer(().append(sb).append() t)).toString();
+psString = (new StringBuffer(().append(sb.toString())
+ .append() t)).toString();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13433] - PS rendering crashes with a run-time exception, No such method
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13433. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13433 PS rendering crashes with a run-time exception, No such method [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 19:31 --- Fix committed to the maintenance branch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 6243] - NullPointerException when attribute flow-name is missing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6243. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6243 NullPointerException when attribute flow-name is missing [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 19:37 --- Fixed in CVS maintenance branch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8698] - NullPointerException when trying to render FO file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8698. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8698 NullPointerException when trying to render FO file [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 19:38 --- *** This bug has been marked as a duplicate of 6243 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 6243] - NullPointerException when attribute flow-name is missing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6243. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6243 NullPointerException when attribute flow-name is missing [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 19:38 --- *** Bug 8698 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Fw: Arabic characters and FOP
Patrick Andries wrote: (*) Does anaybody know how glyphs variants and ligatures (see the substitution feature in Opentype) should be selected from fo ? I believe there is currently no such mechanism. Should we wait until another version of XSL-FO? Extensions ? If I understand the OpenType standard properly, it is supposed to do most of this automatically (it seems to in some applications, but I am not sure whether it is the font or the application doing the work). The question may actually become how to turn it off if you don't want it. See Section 7.8.1 for a discussion of how this ties in with XSL-FO. This is one reason why I am working on trying to get our font support upgraded to handle at least OpenType fonts that are registered at the O/S level (see the fonts thread over the past few days). In the meantime, and for other font types, I suppose a lot of this could be done with some regular expression preprocessing -- it might even be possible to do this within the parser or XSLT transformer. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13464] - part of word missing when broken across pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13464. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13464 part of word missing when broken across pages [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 19:42 --- In absence of sample code demonstrating the problem, I assume it is one of the two problems causing text to be dropped in certain circumstances which have already been fixed in CVS maintenance branch. Please supply a self-contained code sample, or test yourself. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: New Developer Suggestion
Sauyet, Scott wrote: Does anyone have a suggestion about something I could look at fixing / enhancing which is not mission-critical, but which might give me a chance to look at a fair bit of the code? There are some documents in the trunk docs/design directory that have a list of things that need to be done. I last night finished creating a pdf document that can be built from them (a comprehensive FOP Developer Documentation). I can't submit that patch until the last one is committed, but I'll be happy to send it to you by email if you wish. It isn't perfect, but is usable. (I didn't write it, I'm just trying to get it more visible). Victor Mote (mailto:[EMAIL PROTECTED]) Enterprise Outfitters (www.outfitr.com) 2025 Eddington Way Colorado Springs, Colorado 80916 Voice 719-622-0650, Fax 720-293-0044 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fw: Arabic characters and FOP
- Message d'origine - De : J.Pietschmann [EMAIL PROTECTED] À : [EMAIL PROTECTED] Envoyé : 9 oct. 2002 15:30 Objet : Re: Fw: Arabic characters and FOP patrick andries wrote: (*) Does anaybody know how glyphs variants and ligatures (see the substitution feature in Opentype) should be selected from fo ? I believe there is currently no such mechanism. Should we wait until another version of XSL-FO? Extensions ? IIRC the spec mentions it's at the whim of the processor to provide ligatures. There are also various code points assigned to ligatures and presentation forms, for example U+FB01, which could be used in the FO source (at the risk of confusing hyphenation, spell checkers and others). Not a good idea, these code points are deprecated. Ligatures are glyphs not characters, Unicode is about characters (yes, I know there are historical and compatibility exceptions) If such characters are mapped to glyphs by a font, FOP can handle them. The idea with OpenType (the merging of PS1 and TTF fonts) is to do allow to render these ligatures at rendering time (as is necessary with many non-latin based scripts), i.e. within the glyph space. Also, some ligatures are purely discretionary (like the ligated fi you mentioned in U+FB01). This behaviour should be driven by some styling information, I would assume (I want a nice ffl ligature here if present in the font, and here a ct ligature if present). I do not know of any available means to specify this. The same is true for glyph variants (I would like this particular ampersand variant). What are the CSS people doing about this ? Should we follow them ? Also, the discussion whether presentation forms have to be expressed by the characters itself or out of band, for example as fonts, has never ended. Unicode is quite plain about this, I believe it even states somewhere that the Arabic presentations forms were a bad idea . This is at least what the technical director of the Unicode consortium said in an interview I conducted (in French though : http://iquebec.ifrance.com/hapax/pdf/whistler.pdf « Ceci s'est déjà produit : ainsi aucune mise en ouvre Unicode de l'arabe ne se préoccupe du grand nombre de ligatures arabes codées dans Unicode, ligatures dont l'inclusion a constitué une erreur. Les implantations arabes correctes utilisent les caractères arabes de base et étendus et délèguent la formation des ligatures aux polices, comme il se doit.») P. Andries - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Fw: Fw: Arabic characters and FOP
- Message d'origine - De : Victor Mote [EMAIL PROTECTED] À : [EMAIL PROTECTED] Envoyé : 9 oct. 2002 15:39 Objet : RE: Fw: Arabic characters and FOP Patrick Andries wrote: (*) Does anaybody know how glyphs variants and ligatures (see the substitution feature in Opentype) should be selected from fo ? I believe there is currently no such mechanism. Should we wait until another version of XSL-FO? Extensions ? If I understand the OpenType standard properly, it is supposed to do most of this automatically (it seems to in some applications, but I am not sure whether it is the font or the application doing the work). No I do not believe the font or the OS does it automatically, your application does it. Some applications are enabled (make use of the appropriate tables in the font) others not. MS Office tools for instance don't take into account the ligature and substitutions specified for latin scripts...but do it for others script where this is often essential. InDesign does, on the other hand handle the latin ligatures. In the same way, Java supplies you some API to the OpenType tables but does not, I think, interpret them. If you read French see the last part of this article (pp 34-38, 9. Rendu), it is shorter than most of what I've seen written. Sorry for pointing to myself. P. Andries - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Where to start for an RTF renderer (was: New Developer Suggestion)
Hi Scott, On Wednesday 09 October 2002 17:15, Sauyet, Scott (OTS-HAR) wrote: . . . So is integrating other renderers something that the group would eventually like to do? . . . Yes, we've been talking about structure-based renderers (like RTF and MIF) vs. layout-based ones (PDF being the focal point) for some time. The following messages might shed some light on this: http://marc.theaimsgroup.com/?l=fop-devm=102742684000426w=2 http://marc.theaimsgroup.com/?l=fop-devm=102795797014083w=2 . . . As of today, I know nothing about PDF syntax and little about RTF. I figure I'm going to have to learn both. I understand FO fairly well, and I speak Java fairly fluently. What do you think is first priority? . . . As Jeremias said, you're the one who decides what you'd like to work on. I'm personally biased towards the RTF renderer because that's the part I know best, so here are some starting points if you're interested in studying this in more detail and hopefully jumping in. You won't need much RTF knowledge to start with as the jfor RTF library will generate it for you, and no PDF knowledge at all since this RTF renderer will bypass the layout and PDF generation stages completely. Starting points: 1) org/apache/fop/apps/StructureHandler is the base class that receives structure events from the FO tree while the input XSL-FO is being parsed. The main class of the RTF renderer will inherit from this class to transform the events into an RTF document. 2) Package org/apache/fop/mif is an example of how to build a structure-based renderer similar to what the RTF renderer (org/apache/fop/rtf) will be. 3) jfor (www.jfor.org) is currently a separate project that converts XSL-FO to RTF directly, but could take advantage of FOP's much better handling of XSL-FO properties, hence the plan of replacing jfor by a FOP RTF renderer. 4) My suggestion is to first use the RTF library from jfor in binary form, by including jfor's jar in the FOP distribution, to create the RTF document from the StructureHandler events. The current jfor code does a similar thing where the jfor Converter (jfor/jfor/converter/Converter) uses SAX events to drive the jfor RTF library. Later, when FOP becomes better than jfor at generating RTF, we can move the jfor RTF library code into the FOP codebase. I'd like this to happen in a second stage to avoid having to maintain two RTF libraries while both projects coexist. Hope this helps - feel free to ask any additional questions! -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13464] - part of word missing when broken across pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13464. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13464 part of word missing when broken across pages --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 21:24 --- Created an attachment (id=3408) xml xsl current pdf output - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13464] - part of word missing when broken across pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13464. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13464 part of word missing when broken across pages [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2002-10-09 21:26 --- Added zip file hopefully containing all pertinent xml files. Reopened issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fw: Arabic characters and FOP
patrick andries wrote: There are also various code points assigned to ligatures and presentation forms, for example U+FB01, which could be used in the FO source (at the risk of confusing hyphenation, spell checkers and others). Not a good idea, these code points are deprecated. Ligatures are glyphs not characters, Unicode is about characters (yes, I know there are historical and compatibility exceptions) I should have added drawing the wrath of the Unicode folks to the risks :) Also, some ligatures are purely discretionary (like the ligated fi you mentioned in U+FB01). This behaviour should be driven by some styling information, I would assume (I want a nice ffl ligature here if present in the font, and here a ct ligature if present). I do not know of any available means to specify this. The same is true for glyph variants (I would like this particular ampersand variant). Variants should probably represented by different fonts. I *hope* fonts which have glyph variants for certain characters are rare enough... As for ligatures, AFAIK they follow established rules, and therefore you have basically four options: - professional: follow the established rules as far as possible - artistic: make your own rules and follow them - plain: never do ligatures - lousy: random behaviour I think ligatures could explicitely prevented by inserting some zero width characters (non-breaking spaces or joiners?). What are the CSS people doing about this ? It seems there are more pressing problems to solve. I'm not familiar with recent CSS3 developments though. Also, the discussion whether presentation forms have to be expressed by the characters itself or out of band, for example as fonts, has never ended. Unicode is quite plain about this, I believe it even states somewhere that the Arabic presentations forms were a bad idea . Yes, Unicode is explicit about this. But there is still a sizeable fraction left which thinks otherwise... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fw: Arabic characters and FOP
- Message d'origine - De : J.Pietschmann [EMAIL PROTECTED] À : [EMAIL PROTECTED] Envoyé : 9 oct. 2002 17:27 Objet : Re: Fw: Arabic characters and FOP patrick andries wrote: There are also various code points assigned to ligatures and presentation forms, for example U+FB01, which could be used in the FO source (at the risk of confusing hyphenation, spell checkers and others). Not a good idea, these code points are deprecated. Ligatures are glyphs not characters, Unicode is about characters (yes, I know there are historical and compatibility exceptions) I should have added drawing the wrath of the Unicode folks to the risks :) Also, some ligatures are purely discretionary (like the ligated fi you mentioned in U+FB01). This behaviour should be driven by some styling information, I would assume (I want a nice ffl ligature here if present in the font, and here a ct ligature if present). I do not know of any available means to specify this. The same is true for glyph variants (I would like this particular ampersand variant). Variants should probably represented by different fonts. I *hope* fonts which have glyph variants for certain characters are rare enough... They will be more and more of them with OpenType. I think ligatures could explicitely prevented by inserting some zero width characters (non-breaking spaces or joiners?). Yes, but this does not allow to select many different behaviours. What are the CSS people doing about this ? It seems there are more pressing problems to solve. I'm not familiar with recent CSS3 developments though. Well, it depends on your constituency : OpenType is very valuable to non-latin scripts and to fine latin typography. Also, the discussion whether presentation forms have to be expressed by the characters itself or out of band, for example as fonts, has never ended. Unicode is quite plain about this, I believe it even states somewhere that the Arabic presentations forms were a bad idea . Yes, Unicode is explicit about this. But there is still a sizeable fraction left which thinks otherwise... Well, as long as they use Unicode ;-) This is also the philosophy adopted by OpenType. But we can leave that to later and follow what other standards will be coming up with for finer controls. P. Andries - o - O - o - Unicode en français : http://hapax.iquebec.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: documentation
Victor Mote schrieb: FOP Developers: I submitted a patch (through Bugzilla, for trunk) that fixes some problems in the pdfdoc build. I realize that Joerg is doing some work in that area as well, and I don't mean to step on any of that, but I am not sure exactly what that work involves, so I pressed forward. (BTW, my apologies to Joerg -- I think I have mis-Romanized his name in some previous postings). My purpose here is to be able to generate a downloadable PDF that is the Forrest offers one PDF per page at the moment (see http://outerthought.net/forrest/ for example) Item 1: The 0.20.4 release does not seem to have the fo.pdf file included, probably because the xmldoc files aren't in the maintenance branch (to build Because pdf generation was broken.. the pdfdocs, use the FOP classes from the maintenance branch on the xml-docs files in the trunk). Since we don't plan to do many more releases from the maintenance branch, I don't know whether it is easier to a) copy the files from trunk to maintenance, b) just generate the pdf from the trunk include it with the maintenance release, or c) not include the document in the release. I'm too not sure what's the best .. Some time ago we decided to maintain the docs in the trunk only. For the 0.20.3 release I copied the xml-sources to the maintenance branch and build the docs there. For FOP 0.20.4 I did build the html-docs within the trunk and copied the html to the distribution because stylebook was (and still is) broken in the maintenance branch (I think xerces1 is needed) for example). Equally important, I want to beef up some of the content areas, especially the FAQ. (It has been well-documented on this list that nobody reads the FAQ, but I need a place to write such things just for my own benefit :-) ). IIRC Joerg has done some work on the (new) FAQ. (And I'm sure at least some people will read the FAQ) Item 3: This is really a question about content organization. I would like to split the documentation into two groups, user and developer, and in We already have some kind of developer documentation (called design docs). See http://xml.apache.org/fop/design/index.html, sources are in docs/design. please let me know if you have general objections. Also, this may have web site and Forrest ramifications (I am unclear on how our web site is currently generated), so there may be implementation objections as well. It's quite complicated at the moment and Forrest should improve this but I don't see how this will happen at the moment. Ok. IMHO the next step should be the migration of the current docs to forrest (Joerg?) Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: New Developer Suggestion
Sauyet, Scott (OTS-HAR) wrote: So what I was hoping for is a suggestion for something that I can work on that might be useful, but not critical to any immediate plans, ideally something that overlaps little with currently active portions of the project. There were no replies yesterday. Well, I thought I wait for one of the lead developers to surface. First, you'll have to decide whether you want to work on the redesigned code (CVS HEAD), or fix bugs, or do some experiments in the maintenance branch. Either way has it's pros and cons. Picking work for the maintenance branch is easy: there's bugzilla, and the list. The advantage is taht you might immediately help some people, the drawback is that your work is lost after the maintenance branch is abandoned, and you probably can't take much to CVS HEAD. For working on HEAD, pick an area: - layout core - a renderer - the font subsystem - API and configuration - parsing and property resolution - FO extensions Expertise neede for the layout core - Java - intimate XSLFO knowledge, up to language lawyering - layout algorithms (and TR14) - the current design There is a task list, as already noted. A small task not on the list would be to provide the Unicode character propery DB. For a renderer, you'll need mainly knowledge of the rendered format. A small, self containing task would be implementing PDF encryption. There's also a task list. Font subsystem: - the metric file generators probably need lots of fixes. Get a lot of fonts from public directories and other sources and try them. - support for other font file formats - improve usability of the font metrics generators (auto format detection, write a GUI, leverage platform specific repositories) API and configuration: search the list for the discussions - get rid of static configuration data - redesign API with emphasis on easy embedding - URI resolving for images and font files - configurable image chaching - configurable image format detection and handling - auto-detection of image format support (in particular JAI vs. JIMI) FO extensions - author and other information for PDF and perhaps other formatss - cache=yes|no for external-graphics - embed forms and JS stuff in PDF. - embedding binary image formats, for example base64 encoded in instream-foreign-object - look at MathML support - dig out a processor which produces charts and graphs form some marked up data and tie it into instream-foreign-object J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: documentation
Christian Geisert wrote: Ok. IMHO the next step should be the migration of the current docs to forrest (Joerg?) Migration to forrest DTDs. I seem to have lost track of recent changes, and I'm still unwilling to force everyone to use forrest, which includes Cocoon, simply to build the docs, which is unfortunately required if you want to use forrest's XSLT unchanged. I'm almost done, only a few small issues remain (one is that I'm in horror of doing large additions and deletions to the source tree). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: New Developer Suggestion
J.Pietschmann wrote: ... For working on HEAD, pick an area: - layout core - a renderer - the font subsystem - API and configuration - parsing and property resolution Don't pick this one. There is definitely a lot of work going on in this area, which will at least be relevant to HEAD. - FO extensions Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fw: Arabic characters and FOP
Oleg, Thanks for this. I just had a look at java.text.Bidi, and was led inexorably into java.awt.font, and from there back to bedrock - java.lang.Character. It's Wonderland in there, and I haven't had time to digest it, but it looks as though all of the attributes from the Unicode character database are now encoded in java.lang.Character. I.e. the CDB is available in 1.4. It was also interesting to see that a significant subset of the CDB has been available since 1.1, notable omissions being the BIDI characteristics. How is bidi support accessed in 1.3? Must you make your own determinations of directionality, or has the CDB BIDI data also been smuggled in? Peter Oleg Tkachenko wrote: patrick andries wrote: I'm willing to help (slowly) implementing the bidi support (contextualisation and bidi algorithms). Is someone else busy doing it ? Is the time ripe to do so ? Implementation of bidi algorithm itself is not a problem as java has already bidi support since jdk1.3 (it's hidden in 1.3 and revealed in 1.4 in form of java.text.Bidi class). So I believe there are no obstacles for redesigned fop to implement bidi support. PS.Actually it's even feasible to produce hebrew pdf using fop right now (well, under certain circumstances). -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Fw: Arabic characters and FOP
Patrick, It remains to be seen how the 1.4 BIDI handling can be integrated with FOP's layout, and how BIDI processing can be gracefully declined for users not running 1.4. As Unicode and i18n are your strengths, I think your input on this would be very valuable. Perhaps Oleg is already considering the issues, in which case you could work together. Peter patrick andries wrote: - Message d'origine - De : Oleg Tkachenko [EMAIL PROTECTED] patrick andries wrote: Good, no need to help thus. I didn't say that! Volunteers are desperately needed, they are blood of fop project, so if you are willing - you are welcome. Look at today's New Developer Suggestion thread, for example. Okay, okay. I will have a look at it. My own strengths are Unicode, i18n (I still believe you must understand what you are doing and test the different scripts even if Java does most of the job) and fonts (OpenType for instance(*)). I would like to help (not alone...) give the best support in this area, but I'm willing to help (slowly) in other areas in the mean time if the new code is not yet ready to add these features. I will have a look at the todo list and the state of the code and come back (privately) when I have some time. Patrick Andries (member of the Canadian character set committee translator for the ISO JT/SC2/GT2) http://hapax.iquebec.com -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo FOAttributes.java
pbwest 2002/10/09 20:16:12
Modified:src/org/apache/fop/fo Tag: FOP_0-20-0_Alt-Design
FOAttributes.java
Log:
Remove xmlns attributes before processing.
Delete Attributes object from event after processing.
Revision ChangesPath
No revision
No revision
1.1.2.8 +10 -4 xml-fop/src/org/apache/fop/fo/Attic/FOAttributes.java
Index: FOAttributes.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/Attic/FOAttributes.java,v
retrieving revision 1.1.2.7
retrieving revision 1.1.2.8
diff -u -r1.1.2.7 -r1.1.2.8
--- FOAttributes.java 9 Oct 2002 05:57:49 - 1.1.2.7
+++ FOAttributes.java 10 Oct 2002 03:16:12 - 1.1.2.8
@@ -114,6 +114,10 @@
for (int i = 0; i attributes.getLength(); i++) {
String attrUri = attributes.getURI(i);
String attrLocalname = attributes.getLocalName(i);
+String attrQName = attributes.getQName(i);
+int sep = attrQName.indexOf(':');
+String prefix = attrQName.substring(0, (sep == -1 ? 0 : sep));
+if (prefix.equals(xmlns)) break;
String attrValue = attributes.getValue(i);
int attrUriIndex = foNode.namespaces.getURIIndex(attrUri);
@@ -132,7 +136,7 @@
} catch (PropertyException e) {
// Not known - ignore
MessageHandler.errorln(event.getQName() +
- + attributes.getQName(i)
+ + attrQName
+ not recognized. Ignoring.);
}
} else { // Not the XSL FO namespace
@@ -169,6 +173,8 @@
foAttrKeys = (Integer[])(foAttrMap.keySet().toArray(integerArray));
Arrays.sort(foAttrKeys);
}
+// Finished with the Attributes object
+event.setAttributes(null);
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo/expr PropertyParser.java
pbwest 2002/10/09 20:27:01
Modified:src/org/apache/fop/fo/expr Tag: FOP_0-20-0_Alt-Design
PropertyParser.java
Log:
Allow IntegerType PropertyValues as arguments to parseAdditiveExpr() and
parseUnaryExpr().
Restructure parseMultiplicativeExpr() to include arithmetic exceptions.
Revision ChangesPath
No revision
No revision
1.5.2.14 +156 -62 xml-fop/src/org/apache/fop/fo/expr/PropertyParser.java
Index: PropertyParser.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/expr/PropertyParser.java,v
retrieving revision 1.5.2.13
retrieving revision 1.5.2.14
diff -u -r1.5.2.13 -r1.5.2.14
--- PropertyParser.java 9 Oct 2002 06:02:51 - 1.5.2.13
+++ PropertyParser.java 10 Oct 2002 03:27:01 - 1.5.2.14
@@ -232,26 +232,99 @@
}
/**
+ * Generate an arithmetic error string.
+ * @return arithmetic error message.
+ */
+private String arithErrorStr() {
+return Arithmetic operator not followed by Numeric or integer:
++ getExpr();
+}
+
+/**
* Try to parse an addition or subtraction expression and return the
* resulting PropertyValue.
*/
private PropertyValue parseAdditiveExpr() throws PropertyException {
// Evaluate and put result on the operand stack
-System.out.println(parseAdd);
+//System.out.println(parseAdd);
PropertyValue prop = parseMultiplicativeExpr();
-loop:
+PropertyValue pv;
+outer:
for (; ; ) {
-switch (currentToken) {
-case PLUS:
-next();
-((Numeric)prop).add((Numeric)parseMultiplicativeExpr());
-break;
-case MINUS:
-next();
-((Numeric)prop).subtract((Numeric)parseMultiplicativeExpr());
-break;
+inner:
+switch (prop.getType()) {
+case PropertyValue.NUMERIC: {
+switch (currentToken) {
+case PLUS:
+next();
+pv = parseMultiplicativeExpr();
+switch (pv.getType()) {
+case PropertyValue.NUMERIC:
+((Numeric)prop).add((Numeric)pv);
+break inner;
+case PropertyValue.INTEGER:
+((Numeric)prop).add((double)
+(((IntegerType)pv).getInt()));
+break inner;
+default:
+throw new PropertyException(arithErrorStr());
+}
+case MINUS:
+next();
+pv = parseMultiplicativeExpr();
+switch (pv.getType()) {
+case PropertyValue.NUMERIC:
+((Numeric)prop).subtract((Numeric)pv);
+break inner;
+case PropertyValue.INTEGER:
+((Numeric)prop).subtract((double)
+ (((IntegerType)pv).getInt()));
+break inner;
+default:
+throw new PropertyException(arithErrorStr());
+}
+default:
+break outer;
+}
+}
+case PropertyValue.INTEGER: {
+int intVal = ((IntegerType)prop).getInt();
+switch (currentToken) {
+case PLUS:
+next();
+pv = parseMultiplicativeExpr();
+switch (pv.getType()) {
+case PropertyValue.NUMERIC:
+prop = ((Numeric)pv).add((double)intVal);
+break inner;
+case PropertyValue.INTEGER:
+((IntegerType)prop).setInt(intVal +
+((IntegerType)pv).getInt());
+break inner;
+default:
+throw new PropertyException(arithErrorStr());
+}
+case MINUS:
+next();
+pv = parseMultiplicativeExpr();
+switch (pv.getType()) {
+case PropertyValue.NUMERIC:
+((Numeric)pv).add((double)(-intVal));
+prop = ((Numeric)pv).negate();
+break inner;
+case PropertyValue.INTEGER:
+
