Re: API discussion
On 03.08.2005 02:20:39 Andreas L Delmelle wrote: On Aug 2, 2005, at 11:14, Jeremias Maerki wrote: On 01.08.2005 18:31:35 Andreas L Delmelle wrote: snip/ I'm not fully happy either, especially, after I put in the classloader stuff. My proposal would be to do the same I did in Barcode4J: Let's create a cli package with the whole command-line stuff in there. See: http://cvs.sourceforge.net/viewcvs.py/barcode4j/barcode4j/src/java/ org/krysalis/barcode4j/cli/ Funny, right before I read your reply and without having looked at Barcode4J, that was EXACTLY what I was thinking about. That way, it becomes possible to build a JAR without the CLI classes, for people that hardly ever use FOP from a console. Those that need only occasional runs via CLI need simply an additional jar on their classpath that contains only FOP's CLI classes. It's not that there are many, but still, for the purists this means that they don't need to contaminate their environment with those classes (that are not re-usable in other contexts: see Joerg's remark earlier on). Plus: separating the CLI means that we're more at liberty to add dependencies there without forcing our API-users to drag them in as well. Uhm, you know how much space the CLI part currently takes up in fop.jar? 12KB out of 1400KB (two and a half files ATM). And the classes don't even get loaded if fop.jar is used embedded only. I can understand if people want a stand-alone RTF library or if they want SVG support to be optional, but this. H. (Ideas? Still a wild one ATM, but Jakarta Commons' Launcher seemed interesting: IIC, it can be used to handle the tasks we now deal with in our startup scripts --which would mean that we have to maintain that stuff only in one place--, offers fine-grained control over the class-loading.) This would add more complexity and an additional dependency, where the dynamic class loading for the CLI is already solved with a few lines. I don't see the benefit, sorry. I'd rather have a Win32 executable for people who don't know a thing about Java. I was thinking about doing this many times now. snip / As a side note: Keep in mind that I've written a general API which easily handles calling FOP 0.20.5, FOP Trunk, JFOR, FOray and even Batik for the conversion of XSL-FO or SVG to PDF, PS, Print etc. Yes, I remember. Of course, that is one side: a matter of conforming to a set of interfaces. How we implement them and map the general API to our own is another. So far, I was able to map all the FOP-specifics into the JAXG implementation without polluting the interface itself. There might be a few very special use cases that won't be supported but I don't think that's a problem. One thing's for sure: such mapping will be much easier if our specific API is neatly designed, regardless of what the general interfaces look like. Actually, handling FOP Trunk was very easy in JAXG already. There's only the little flaw in the Fop constructor when you actually use a custom-configured Renderer. I'm very much in favor of the idea, and my preference in that area is towards a *very* abstract and stringent general API, even if that would mean that for all of the above apps someone still needs to code API-to-API (specific-to-general) bridges. Evidently, there can be absolutely no references whatsoever to any of those particular applications in the general API --ideally it should be designed by someone who knows nothing about those particular apps' usage patterns, but who understands what a FO or SVG processor is/does (besides being very proficient in Java interface-design, of course :-)) I think I already managed to do all that. There will certainly be a few details to attend to but I'm already using the API in all my code and for almost everything. It is designed to provide for the various XSL-FO implementations what JAXP is for Xerces, Crimson, Xalan, SAXON etc. After all, I'm currently wondering if Xalan or SAXON ever started out as an attempt to write an implementation for JAXP, or if their initial concern was to code a decent XSLT processor and they added the JAXP conformance further on. (I'd guess it lies more in the direction of the latter, but I'm not sure at all) The latter was indeed the case. And, now that JAXP is mentioned: of course, it's beneficial to expose that API's functionality in our own --after all, it's *XSL*-FO--, however, we should probably allow a number of possibilities, ranging from: URL srcFileloc, URL xslFileloc, URL tgtFileloc --we could determine the output target from tgtFileloc's extension (in a lot of situations) over File srcFile, File xslFile, File tgtFile over users passing in their own InputSources, Transformers and OutputStreams, You're talking about convenience methods, right? I'm sure we can provide a small number of them for beginners, but maybe
DO NOT REPLY [Bug 35992] New: - FOP Compliance page update
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=35992. 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=35992 Summary: FOP Compliance page update Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: documentation AssignedTo: fop-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] Jeremias, From fop-dev mailing list: On Wed, 3 Aug 2005 03:03 pm, Jeremias Maerki wrote: On 03.08.2005 08:32:07 Manuel Mall wrote: On Tue, 2 Aug 2005 04:52 pm, Jeremias Maerki wrote: On 02.08.2005 03:18:44 Manuel Mall wrote: ... Sounds good. Thanks a lot! WIP could be replaced by Trunk for now. Done ... If you want to start fill in stuff yourself, you could go through all the testcases in: http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/test/layoutengi ne/testcases/ If you want to run these testcases from the command-line, you can use the testcase2fo.xsl stylesheet in the parent directory of the above. But it's no problem if you send in your changes now. I guess it will only take me about an hour to fill in the second column. I've got a pretty good overview what works and what not. had a look at the test cases there are just too many for manual processing. I rather pick your brain first and if there are any question marks left I would be happy to investigate, write testcases, etc.. I will attach the svn patch file and also a file called skinconf.xsl which is a replacement for the file of the same name in your Forrest main/webapp/skins/pelt/ directory. Note that I am using Forrest 0.7. Happy for you to bounce it back to me after you made your changes to the trunk compliance column. And as said above happy to investigate any items you are unsure about. ... I also noticed that a number of objects and properties are marked as compliant but in the comment column is a remark indicating there is a problem with the compliance. For example: Property border-before-style is marked as compliant but in the comment it says only solid works. Isn't that a partial compliance only? Shall I update all those type of entries to partial? Yes, please, that sounds more reasonable. Done Jeremias Maerki Manuel -- 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 35992] - FOP Compliance page update
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=35992. 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=35992 --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 10:22 --- Created an attachment (id=15860) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15860action=view) Patch to compliance page -- 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 35992] - FOP Compliance page update
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=35992. 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=35992 --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 16:03 --- Jeremias thanks for completing the trunk column - I'll look into the yes? cases in the next day or so. -- 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: svn commit: r227219 - /xmlgraphics/fop/trunk/src/documentation/content/xdocs/compliance.ihtml
Jeremias Maerki wrote: Initial values for Trunk column. No guarantees! Jeremias, Manuel, you have done a great job! I find it very useful and stimulating to have such a comprehensive to do list at hand! Just a few notes: [page-number-citation] [Trunk] After the page number is known, no relayout is performed. The appearance may be suboptimal depending on the use case. The same problem affects page-number too. I have started looking at this, I will soon post a message with my first findings and ideas. [line-stacking-strategy] [Trunk] TODO TBD font-height is explicitly implemented; the alternative behaviour (when line-stecking-strategy is not font-height) should match the one prescribed for max-height. The recommendation (7.15.16) states that Implementations must support at least the max-height and font-height values defined in this Recommendation, and may treat line-height as if max-height had been specified, so we should be in a consistent state. [text-align] Only start, end, center and justify are supported [text-align-last] Only start, end, center and justify are supported Implementing inside and outside should not be difficult. During the linebreaking, they could be handled just as start (using effectiveAlignment); during the addAreas() phase, when the page number should be known, the computent difference could be either interpreted as a left indent (to implement ouside in a odd page or inside in an even one) or ignored. [letter-spacing] yes? As far as I can remember it should work. Regards Luca
DO NOT REPLY [Bug 35998] New: - [PATCH] rtflib independance from 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=35998. 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=35998 Summary: [PATCH] rtflib independance from FOP Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] See the threads in the fop developers' mailing-list with rtflib independance from FOP in the subject for more info. -- 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 35998] - [PATCH] rtflib independance from 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=35998. 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=35998 --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 18:33 --- Created an attachment (id=15863) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15863action=view) rough svn patch on fop-trunk\src\java\org\apache\fop\render\rtf -- 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 36000] - PDF page margins larger, different than PS rendering
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=36000. 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=36000 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 20:01 --- I'm sure that is your print setting in Acrobat Reader: http://xml.apache.org/fop/faq.html#pdf-print-contortion FOP has no bug in that area. -- 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 36000] - PDF page margins larger, different than PS rendering
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=36000. 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=36000 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 20:21 --- (In reply to comment #1) I'm sure that is your print setting in Acrobat Reader: http://xml.apache.org/fop/faq.html#pdf-print-contortion FOP has no bug in that area. It's not the just the printing of the PDF but the viewing! -- 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 36000] - PDF page margins larger, different than PS rendering
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=36000. 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=36000 --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 20:22 --- (In reply to comment #2) (In reply to comment #1) I'm sure that is your print setting in Acrobat Reader: http://xml.apache.org/fop/faq.html#pdf-print-contortion FOP has no bug in that area. It's not the just the printing of the PDF but the viewing! Oops. Ignore that last comment -- I was confused -- that was not supposed to post. Thanks for your help -- sorry to waste your time on this one! (but it sure helped me out) -- 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.
Handling of block-level FOs inside fo:inline and related
fo:inline, fo:bidi-override and fo:inline-container are all inline-level FOs and all allow block-level content. Currently, they are not implemented. See, for example, inline1.xml which fails with a ClassCastException. The FO I skipped here is fo:wrapper which in the current implementation doesn't really wrap its content and therefore avoids an important problem: Inline FOs return element lists processed by the line breaker. They don't have a way to return elements for the page breaker. I've been asked to do a time estimate for implementing fo:inline. fo:inline is particularly important since a lot of people use empty fo:blocks, for example, to mimic newlines. Now I wonder about how to implement fo:inline. The only way I came up with was to try normalizing the FO tree and to let fo:inline be what it currently is: Input: fo:block color=blueblah blah fo:inline font-style=italicblahfo:block/blah/fo:inlineblah/fo:block Output: fo:block color=blueblah blah fo:inline font-style=italicblah/fo:block fo:block color=blue font-style=italic/ fo:block color=blue fo:inline font-style=italicblah/fo:inlineblah/fo:block or: fo:block color=blue fo:blockblah blah fo:inline font-style=italicblah/fo:block fo:block font-style=italic/ fo:blockfo:inline font-style=italicblah/fo:inlineblah/fo:block /fo:block Replicating the properties of an fo:inline to a copy shouldn't be much of a problem. Replicating the properties for the contained block might already me a little more difficult because of the whole inheritance stuff. Is there another way? A better way? Any ideas? For fo:bidi-override, the same approach would be used. For fo:inline-container this whole thing is easier since it generates a viewport/reference pair, so it will ultimately need its own breaker (like absolutely positioned block-containers). Jeremias Maerki
DO NOT REPLY [Bug 35998] - [PATCH] rtflib independance from 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=35998. 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=35998 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 21:35 --- Merci, Guillaume. Patch applied with modifications. I've changed the generator name a bit and reconstructed the moved BorderAttributesConverter that was missing in the patch. Otherwise, your changes look good. -- 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: Help to convert an XML document to another format
Hi All, Thanks to all who invested time to help me out. What I have done is a cocktail. Using an XSL stylesheet and xslt2.exe, I have now a well formed HTML file. Next thing, I am now installing Ununtu 5.10 in order to try FO. Best wishes and keep up the good jib, Jimmy -Original Message- From: Carlos M. S. Bento Nogueira [mailto:[EMAIL PROTECTED] Sent: Sunday, July 31, 2005 11:37 PM To: fop-users@xmlgraphics.apache.org; [EMAIL PROTECTED] Cc: fop-dev@xmlgraphics.apache.org Subject: Re: Help to convert an XML document to another format Hi! I'm using apache cocoon to pass xml documents from xml to html and from xml to pdf. Check cocoon features on http://cocoon.apache.org/2.1/features.html and see if it fits your problem. It is not an easy framework for non-programmers though. CarlosN. On Sun, 31 Jul 2005, Jimmy Pierre wrote: Greetings, I am not a programmer, so when I encounter the type of problem that I will expose, I am ever so grateful :-) I have a report per machine and the report can only be saved in XML. I would like to now convert the report in whatever, HTML, DOC, PDF, spreadsheet etc. The issue is that I need to be able to exploit it. I have posted the report on my site: http://www.cisware.co.uk/xmlproblem http://www.cisware.co.uk/xmlproblem it's only 20 K Anybody could give me a tool to just convert this thing? I am fluent in English/French.. Best wishes, Jimmy --
DO NOT REPLY [Bug 36004] - [PATCH] Block content in inline content
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=36004. 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=36004 --- Additional Comments From [EMAIL PROTECTED] 2005-08-03 22:14 --- Created an attachment (id=15868) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15868action=view) My work on block content in inline content -- 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: Handling of block-level FOs inside fo:inline and related
I have been working on that, rather slowly, as I do not have much time. My solution for the Knuth Elements is that each inline level LM returns a list of Knuth sequences, inline or block. This part works well. The code works well for fo:inline with inline or block content. I have not yet implemented it in other LMs except BasicLinkLM. I have done some work for rendering. But I am not very familiar with that part of FOP, and have not yet paid attention to details. I will post a patch on Bugzilla. The present state of the code breaks other inline level LMs as they do not yet return the correct data structure for the next Knuth elements. Therefore I cannot commit it to HEAD. I could commit it into a branch. For the next few weeks I will also spend a lot of time on other things. So, if I am progressing too slowly, someone else should feel free to take this further. Regards, Simon On Wed, Aug 03, 2005 at 08:30:56PM +0200, Jeremias Maerki wrote: fo:inline, fo:bidi-override and fo:inline-container are all inline-level FOs and all allow block-level content. Currently, they are not implemented. See, for example, inline1.xml which fails with a ClassCastException. The FO I skipped here is fo:wrapper which in the current implementation doesn't really wrap its content and therefore avoids an important problem: Inline FOs return element lists processed by the line breaker. They don't have a way to return elements for the page breaker. I've been asked to do a time estimate for implementing fo:inline. fo:inline is particularly important since a lot of people use empty fo:blocks, for example, to mimic newlines. Now I wonder about how to implement fo:inline. The only way I came up with was to try normalizing the FO tree and to let fo:inline be what it currently is: Input: fo:block color=blueblah blah fo:inline font-style=italicblahfo:block/blah/fo:inlineblah/fo:block Output: fo:block color=blueblah blah fo:inline font-style=italicblah/fo:block fo:block color=blue font-style=italic/ fo:block color=blue fo:inline font-style=italicblah/fo:inlineblah/fo:block or: fo:block color=blue fo:blockblah blah fo:inline font-style=italicblah/fo:block fo:block font-style=italic/ fo:blockfo:inline font-style=italicblah/fo:inlineblah/fo:block /fo:block Replicating the properties of an fo:inline to a copy shouldn't be much of a problem. Replicating the properties for the contained block might already me a little more difficult because of the whole inheritance stuff. Is there another way? A better way? Any ideas? For fo:bidi-override, the same approach would be used. For fo:inline-container this whole thing is easier since it generates a viewport/reference pair, so it will ultimately need its own breaker (like absolutely positioned block-containers). Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl
Re: rtflib independance from FOP (continued) + JAFOG
Le 2 août 05, à 12:36, Chris Bowditch a écrit : ...Is this a typo, or did you mean to say FOP is *not* the most up-to-date place for thr RTF Renderer? I thought the JFOR project had stopped and since integrating the RTF Renderer into FOP, several improvements had been made to the RTF Renderer in FOP... Yes, nearly nothing much has happened on the jfor side since the code was donated to FOP. I haven't looked closely at the FOP rtflib stuff but I guess it's at least as good as jfor's, and getting better. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Handling of block-level FOs inside fo:inline and related
Jeremias Maerki wrote: fo:inline, fo:bidi-override and fo:inline-container are all inline-level FOs and all allow block-level content. I think an inline-container should create a single area as a first approximation, unless the content fills a whole page. Therefore it shouldn't pose a real problem in this context. I have no idea how an inline container whose content overflows the page bpd should be handled. Fortunately, in the case of changing the write mode e.g. from lr-tb to tb-lr, the ipd of the content in the inline container has to be fixed, which translates to a fixed bpd in the context of the ancestor block of the inline container. Unless I misunderstood the spec, of course. The real headache is caused by the anticipation that the most common use case for inline container will be embedding tables inline, for all kind of purposes... J.Pietschmann
Re: Handling of block-level FOs inside fo:inline and related
I'd appreciate if you'd take this to a branch (or I can do it for you with the patch you posted). That way everybody can help and branches are really easy with SVN now. ATM I only have to do an estimate not necessarily the actual implementation. My next scheduled task is the PS Renderer. So I don't know when I will have time to work on it, but I'll definitely have a closer look. Thanks for making the patch! On 03.08.2005 22:00:27 Simon Pepping wrote: I have been working on that, rather slowly, as I do not have much time. My solution for the Knuth Elements is that each inline level LM returns a list of Knuth sequences, inline or block. This part works well. The code works well for fo:inline with inline or block content. I have not yet implemented it in other LMs except BasicLinkLM. I have done some work for rendering. But I am not very familiar with that part of FOP, and have not yet paid attention to details. I will post a patch on Bugzilla. The present state of the code breaks other inline level LMs as they do not yet return the correct data structure for the next Knuth elements. Therefore I cannot commit it to HEAD. I could commit it into a branch. For the next few weeks I will also spend a lot of time on other things. So, if I am progressing too slowly, someone else should feel free to take this further. Regards, Simon On Wed, Aug 03, 2005 at 08:30:56PM +0200, Jeremias Maerki wrote: fo:inline, fo:bidi-override and fo:inline-container are all inline-level FOs and all allow block-level content. Currently, they are not implemented. See, for example, inline1.xml which fails with a ClassCastException. The FO I skipped here is fo:wrapper which in the current implementation doesn't really wrap its content and therefore avoids an important problem: Inline FOs return element lists processed by the line breaker. They don't have a way to return elements for the page breaker. I've been asked to do a time estimate for implementing fo:inline. fo:inline is particularly important since a lot of people use empty fo:blocks, for example, to mimic newlines. Now I wonder about how to implement fo:inline. The only way I came up with was to try normalizing the FO tree and to let fo:inline be what it currently is: Input: fo:block color=blueblah blah fo:inline font-style=italicblahfo:block/blah/fo:inlineblah/fo:block Output: fo:block color=blueblah blah fo:inline font-style=italicblah/fo:block fo:block color=blue font-style=italic/ fo:block color=blue fo:inline font-style=italicblah/fo:inlineblah/fo:block or: fo:block color=blue fo:blockblah blah fo:inline font-style=italicblah/fo:block fo:block font-style=italic/ fo:blockfo:inline font-style=italicblah/fo:inlineblah/fo:block /fo:block Replicating the properties of an fo:inline to a copy shouldn't be much of a problem. Replicating the properties for the contained block might already me a little more difficult because of the whole inheritance stuff. Is there another way? A better way? Any ideas? For fo:bidi-override, the same approach would be used. For fo:inline-container this whole thing is easier since it generates a viewport/reference pair, so it will ultimately need its own breaker (like absolutely positioned block-containers). Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl Jeremias Maerki
Re: Handling of block-level FOs inside fo:inline and related
On 03.08.2005 22:26:51 J.Pietschmann wrote: Jeremias Maerki wrote: fo:inline, fo:bidi-override and fo:inline-container are all inline-level FOs and all allow block-level content. I think an inline-container should create a single area as a first approximation, unless the content fills a whole page. Therefore it shouldn't pose a real problem in this context. That's what I thought. I have no idea how an inline container whose content overflows the page bpd should be handled. Well, if it simply generates a single box, that box is broken as a whole. If it doesn't fit the page: Mep! :-) I've no idea if an inline-container is supposed to be broken at all and if yes, how. Fortunately, in the case of changing the write mode e.g. from lr-tb to tb-lr, the ipd of the content in the inline container has to be fixed, which translates to a fixed bpd in the context of the ancestor block of the inline container. Unless I misunderstood the spec, of course. The real headache is caused by the anticipation that the most common use case for inline container will be embedding tables inline, for all kind of purposes... J.Pietschmann Jeremias Maerki
DO NOT REPLY [Bug 36007] New: - letter-spacing property causes ClassCastException
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=36007. 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=36007 Summary: letter-spacing property causes ClassCastException Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] The following fo: fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:svg=http://www.w3.org/2000/svg; fo:layout-master-set fo:simple-page-master master-name=normal page-width=5in page-height=5in fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=normal white-space-collapse=true fo:flow flow-name=xsl-region-body fo:blockfo:inline letter-spacing.optimum=2pt letter-spacing.minimum=0pt letter-spacing.maximum=4ptD/fo:inlineefault/fo:block /fo:flow /fo:page-sequence /fo:root causes a java.lang.ClassCastException: org.apache.fop.layoutmgr.KnuthPenalty Exception. It only happens if the fo:inline with the letter-spacing property is the first element in the block. It also only happens for the letter-spacing property set as space as shown above, that is something like: fo:blockfo:inline letter-spacing=2ptD/fo:inlineefault/fo:block is not causing an exception. -- 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 36008] - [PATCH] letter-spacing testcases
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=36008. 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=36008 --- Additional Comments From [EMAIL PROTECTED] 2005-08-04 04:16 --- Created an attachment (id=15873) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15873action=view) letter-spacing2.xml - Second set of tests for the letter-spacing property -- 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 36010] - [PATCH] word-spacing testcases
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=36010. 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=36010 --- Additional Comments From [EMAIL PROTECTED] 2005-08-04 05:08 --- Created an attachment (id=15876) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15876action=view) word-spacing1.xml - First set of test cases for word-spacing property -- 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 36010] - [PATCH] word-spacing testcases
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=36010. 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=36010 --- Additional Comments From [EMAIL PROTECTED] 2005-08-04 05:11 --- Created an attachment (id=15880) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15880action=view) word-spacing4.xml - Fourth set of test cases for word-spacing property -- 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 36011] New: - Setting word-spacing on justified blocks removes justification
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=36011. 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=36011 Summary: Setting word-spacing on justified blocks removes justification Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] Use the second set of test cases attached to Bug #36010 as an example. When setting word-spacing=0pt (which should (nearly) be the same as word-spacing=normal or no word-spacing at all) the block is not justified. Same applies for the word-spacing=-3pt example. However, word-spacing=normal works fine as does something like fo:block text-align=justify word-spacing.optimum=6pt word-spacing.minimum=3pt word-spacing.maximum=12pt. -- 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.
