RE: AW: RTF: white-space-treatment and linefeed-treatment
> I think you can flush the queue each time a nested block > starts and each time a block ends. I have no queue to flush. All i do is ignoring all event handler functions until endBlock is called for a not-nested Block. Then i iterate recursively through its children an call all appropriate event handlers. For this purpose i have implemented a reference counter. Eachtime startBlock is entered the counter is incremented. Eachtime endBlock is entered the counter is decremented. So when the reference counter reachs 0, a not-nested block is finished and i can process all deferred FOs. Works quite good. Kind regards Peter Herweg > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > J.Pietschmann > Sent: Tuesday, January 27, 2004 9:16 PM > To: [EMAIL PROTECTED] > Subject: Re: AW: RTF: white-space-treatment and linefeed-treatment > > > Peter Herweg wrote: > > Maybe difficulties is the wrong word. Just a thing i have to > care for. If i > > do the processing of FOs in endBlock, i have to suppress the processing > > within nested blocks. Or the nested blocks will be processed twice. > > I think you can flush the queue each time a nested block > starts and each time a block ends. The start of a new block > forces a new line, so you can finish the current line, > including whitespace processing. > > J.Pietschmann
Re: AW: RTF: white-space-treatment and linefeed-treatment
Peter Herweg wrote: Maybe difficulties is the wrong word. Just a thing i have to care for. If i do the processing of FOs in endBlock, i have to suppress the processing within nested blocks. Or the nested blocks will be processed twice. I think you can flush the queue each time a nested block starts and each time a block ends. The start of a new block forces a new line, so you can finish the current line, including whitespace processing. J.Pietschmann
AW: RTF: white-space-treatment and linefeed-treatment
> What are the difficulties for nested blocks? Maybe difficulties is the wrong word. Just a thing i have to care for. If i do the processing of FOs in endBlock, i have to suppress the processing within nested blocks. Or the nested blocks will be processed twice. Kind regards Peter Herweg > -Ursprungliche Nachricht- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Auftrag > von J.Pietschmann > Gesendet: Monday, January 26, 2004 8:58 PM > An: [EMAIL PROTECTED] > Betreff: Re: RTF: white-space-treatment and linefeed-treatment > > > Peter Herweg wrote: > > (2) I defer the processing of all inline-generating, > text-containing FOs, > > and process them in RtfHandler.endBlock. > > I'd say start with this option, although I'm starting to believe we > could and should move whitespace processing to before the invocation > of the structure renderer's character event call. You still have to > delay some output because space before/after a line break must be > stripped for many settings. > > What are the difficulties for nested blocks? > > J.Pietschmann
Re: RTF: white-space-treatment and linefeed-treatment
Peter Herweg wrote: (2) I defer the processing of all inline-generating, text-containing FOs, and process them in RtfHandler.endBlock. I'd say start with this option, although I'm starting to believe we could and should move whitespace processing to before the invocation of the structure renderer's character event call. You still have to delay some output because space before/after a line break must be stripped for many settings. What are the difficulties for nested blocks? J.Pietschmann
RTF: white-space-treatment and linefeed-treatment
Hello, i am currently working on support for white-space-treatment and linefeed-treatment for the RTF module. Of course i don't want to reinvent the wheel, so i tried wanted Block.handleWhiteSpace method to do the job. But when i read the text data which is passed to RtfHandler.characters there is no support for white-space-treatment and linefeed-treatment. The handleWhiteSpace method seems to process the text data at later time. If i loop through Block.children in RtfHandler.endBlock and look for FOText objects the text data is processed correctly. But unfortunately i need the text data in RtfHandler.characters - in RtfHandler.endBlock it's to late. I see following possibilities to solve this problem: (1) I re-implement support for white-space-treatment and linefeed-treatment in the RTF module and call this algorithm from RtfHandler.characters - independend of Block.handleWhiteSpace. (IMHO not a good idea) (2) I defer the processing of all inline-generating, text-containing FOs, and process them in RtfHandler.endBlock. (Maybe it could be difficult to determine when to defer processing and when not. For example i'll have to be carefull with nested fo:block's. Quite difficult.) (3) I defer the processing of all FOs until endPageSequence, and then loop recursively through all children and call startXXX and endXXX events explicitly. (Maybe the best solution. On one hand this would be a quite big revolution for just two properties, on the other hand maybe there are similar issues in future.) Any comments or opinions appreciated. Kind regards Peter Herweg
Re: linefeed-treatment
Keiron Liddle wrote: > > > > Hello > > > > > is rendered to a line which starts with a space character. > > Is this correct? And is the implementation in fop 0.20.4 false, > > which don't considered the starting space character? > ... > So fop 0.20.4 is correct and Fop1.0dev cvs is partially correct but the > layout manager(s) does not suppress the leading space properly. That a > bug probably in the LineLayoutManager. > > I'm not sure where in the spec it talks about suppressing spaces but I'm > sure it is in there somewhere. I just stumbled over this rather old thread while wondering about the above situation. The relevant spec part is the property "suppress-at-line-break". It defaults to "auto" which in turn means suppress is on for code point U+0020 and off for all others. No area is generated (ok, the specs says an area is generated and then deleted 8-)). -- Cappelino Informationstechnologie GmbH Arnd Beißner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: linefeed-treatment
Hi Rainer, On Tue, 2002-11-12 at 00:08, Rainer Garus wrote: > With an actual 1.0dev fop the following part of a fo-file > > > Hello > > > is rendered to a line which starts with a space character. Is this correct? And is >the implementation in fop 0.20.4 false, which don't considered the starting space >character? > > The default value of linefeed-treatment is treat-as-space (7.15.7), so the linefeed >character between ">" and "H" is substituted with a space. Is there a sentence in the >specification suppressing the starting space character? > > Rainer Garus The linefeed is indeed converted into a space as it should. The problem is that when doing the layout it does not suppress the leading space as it should. So fop 0.20.4 is correct and Fop1.0dev cvs is partially correct but the layout manager(s) does not suppress the leading space properly. That a bug probably in the LineLayoutManager. I'm not sure where in the spec it talks about suppressing spaces but I'm sure it is in there somewhere. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
linefeed-treatment
With an actual 1.0dev fop the following part of a fo-file Hello is rendered to a line which starts with a space character. Is this correct? And is the implementation in fop 0.20.4 false, which don't considered the starting space character? The default value of linefeed-treatment is treat-as-space (7.15.7), so the linefeed character between ">" and "H" is substituted with a space. Is there a sentence in the specification suppressing the starting space character? Rainer Garus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Substitute or implementation of linefeed-treatment
Raimund Kammering wrote: So to come to the point: I need to format a document and conserve the line breaks as they are delivered by the parser. So I added a "linefeed-treatment="preserve" to the fo:block but FOP complained that the linefeed-treatment is not supported up till now (I am running FOP 0.20.3)?! Try white-space-collapse="false", which also preserves runs of white space. If this isn't desirable, replace your line feed characters with the line separator character U+2028, in XSLT translate($string, , ) PS.: I nearly don't want to ask - but is there anything new concerning the "keep-with" handling - as I said I have been away for some time??? Just search the archive. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Substitute or implementation of linefeed-treatment
Hello, sorry if I missed some discussions in case that this topic has already been addressed - but I haven't been listening to FOP list for some months. So to come to the point: I need to format a document and conserve the line breaks as they are delivered by the parser. So I added a "linefeed-treatment="preserve" to the fo:block but FOP complained that the linefeed-treatment is not supported up till now (I am running FOP 0.20.3)?! Is there an easy solution to my problem?! Any help is welcome. Regards Raimund PS.: I nearly don't want to ask - but is there anything new concerning the "keep-with" handling - as I said I have been away for some time??? -- DESY -MVP- Notkestrasse 85 D-22603 Hamburg Tel.: +49 40 8998 -4903 e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7919] - problem to use attribute linefeed-treatment and line-stacking-strategy
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=7919>. 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=7919 problem to use attribute linefeed-treatment and line-stacking-strategy --- Additional Comments From [EMAIL PROTECTED] 2002-06-03 09:09 --- Use white-space-collapse="false" as a work around. It will preserve line feeds too. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 1998] - linefeed-treatment not understood
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=1998>. 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=1998 linefeed-treatment not understood [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 07:52 --- *** Bug 2127 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: linefeed-treatment="preserve"
Shawn Bedard wrote: > property - "linefeed-treatment" is not implemented yet. > > It seems to me that there has to be a way to get around this. Surely, > someone out there has CRs in their data that they want to render? You can try enclose CR delimited blocks at the XSLT level. The usual approach is to write a recursive template Use this like Put font, spacing and other properties on the enclosing block. If you have mixed content, this is more of a challenging problem, as the approach above wont work. Look at the XSL FAQ and into the XSL mailing list archive for more tricks: http://www.mulberrytech.com/xsl/xsl-list/ HTH J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: linefeed-treatment="preserve"
We do what you are asking. According to our FO expert (not me) using has the side effect (in FOP) of causing FOP to recognize carriage returns. Jim [PARA]Jim Urban - [EMAIL PROTECTED][TAB][PARA]Clinical Connectivity Suite Product Manager[PARA]Suite 295[PARA]500 Park Blvd.[PARA]Itasca, IL 60143[PARA]Voice: (630) 250-3045 x106[PARA]Fax: (630) 250-3046[PARA][PARA]Advancing Healthcare Performance[PARA]www.parkcitysolutions.com[PARA] -Original Message- From: Shawn Bedard [mailto:[EMAIL PROTECTED]] Sent: Monday, April 15, 2002 11:14 AM To: [EMAIL PROTECTED] Subject: linefeed-treatment="preserve" Greetings FOP experts. I am building report engine for tomcat. What I do is stream the data into and XML file and the resulting file is passed to the XSLTInputHandler with appropriate XSLT. Currently everything works quite well, however, all carriage returns in the data are stripped out during the PDF conversion in the XSLTInputHandler. After reading the XSL spec on w3c this seems to be behaving as expected: The default linefeed-treatment is set to be treat-as-space so all CRs are changed to spaces :(. As well, when I try to set linefeed-treatment="preserve" I get the following warning during parsing: property - "linefeed-treatment" is not implemented yet. It seems to me that there has to be a way to get around this. Surely, someone out there has CRs in their data that they want to render? Thanks, Shawn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
linefeed-treatment="preserve"
Greetings FOP experts. I am building report engine for tomcat. What I do is stream the data into and XML file and the resulting file is passed to the XSLTInputHandler with appropriate XSLT. Currently everything works quite well, however, all carriage returns in the data are stripped out during the PDF conversion in the XSLTInputHandler. After reading the XSL spec on w3c this seems to be behaving as expected: The default linefeed-treatment is set to be treat-as-space so all CRs are changed to spaces :(. As well, when I try to set linefeed-treatment="preserve" I get the following warning during parsing: property - "linefeed-treatment" is not implemented yet. It seems to me that there has to be a way to get around this. Surely, someone out there has CRs in their data that they want to render? Thanks, Shawn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7919] New: - problem to use attribute linefeed-treatment and line-stacking-strategy
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=7919>. 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=7919 problem to use attribute linefeed-treatment and line-stacking-strategy Summary: problem to use attribute linefeed-treatment and line- stacking-strategy Product: Fop Version: 0.20.3 Platform: All OS/Version: All Status: NEW Severity: Critical Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] hi I write à tutorial. So I insert code java like sample. So I need to use linefeed-treatment attribute and line-stacking-strategy attribute in order to display in my pdf document code java indented. But this attribute is not implemented. Can you doing something,please. It's importante. Thanks charly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: linefeed-treatment
On Wed, 08 Aug 2001 15:12:19 Gregor N. Purdy wrote: > Thanks for the reply. > > So, does that mean that the entry in src/codegen/foproperties.xml > should be edited so it doesn't say ToBeImplemented? > If its being handled correctly, then we don't need the message to be > printed. If there is some work still to be done before it can be > considered completely supported, perhaps its a small enough task that > I could figure it out... > > If nobody else is working on this, I'll go dig into the spec to see > where the possibilities are discussed and then crawl through the code > to see if I can find the right place(s) to make changes. I've not > contributed code before, so pointers would be appreciated. From a > little find+grep I see that linefeed-treatment is mentioned only in > foproperties.xml and in src/org/apache/fop/fo/flow/Block.java (but > it is only in a comment there). I see that white-space-collapse is > mentioned in a few places. Gregor, It should stay as not implemented until it is at least read properly (reads the value into the correct data type) and is used at least somewhere. If you only found it on Block then that is probably the only place that it applies (directly). To understand what it should do you therefore need to read the information about the property, read about the block element and other places that you may need to look at are the other space handling properties. Then the foproperties.xml should be adjusted to read handle the correct values. Next it needs to be read in Block and handled there. That should get you started at least. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: linefeed-treatment
On Wed, 08 Aug 2001 15:48:59 Elliotte Rusty Harold wrote: > I don't know what's supposed to be happening here, but I have noted that > FOP collapses blank lines in my source code using the Docbook XSLT > stylesheets being discussed. Every other XSL-FO processor leaves the > blank lines where I put them, so I'm pretty sure FOP is doing something > wrong. If it's not linefeed-treatment, then almost certainly something > else is wrong. I think I read the spec wrong. When it says no special it means certain things. The white space should not be collapsed and as a separate issue the linefeeds should still behave as linefeeds. It appears there are three things that can effect whitespace: space-treatment, white-space-collapse and linefeed-treatment. The linefeed treatment acts to override how linefeeds are dealt with (default is "treat as space") depending on the other two. So in this case the linefeeds should appear as new lines in the output and all whitespace should be written to the output. Rule 535: never read any part of the spec without cross referencing at least another 50% I just broke this rule so I could still be wrong. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: linefeed-treatment
I don't know what's supposed to be happening here, but I have noted that FOP collapses blank lines in my source code using the Docbook XSLT stylesheets being discussed. Every other XSL-FO processor leaves the blank lines where I put them, so I'm pretty sure FOP is doing something wrong. If it's not linefeed-treatment, then almost certainly something else is wrong. -- +---++---+ | Elliotte Rusty Harold | [EMAIL PROTECTED] | Writer/Programmer | +---++---+ | The XML Bible, 2nd Edition (Hungry Minds, 2001) | | http://www.ibiblio.org/xml/books/bible2/ | | http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ | +--+-+ | Read Cafe au Lait for Java News: http://www.cafeaulait.org/ | | Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/ | +--+-+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: linefeed-treatment
Keiron -- > > I'm using the docbook-xsl-1.14 tools from docbook.sourceforge.net to > > convert a DocDook XML file into xsl:fo and then using FOP to convert > > that into PDF. I've noticed FOP printing messages like this: > > > > warning: property - "linefeed-treatment" is not implemented yet. > > > > it turns out that docbook-xsl is using that attribute on the fo:block > > elements it creates out of my DocBook elements. > > > > Is linefeed-treatment handling on the radar screen? > > I'm getting the correct output, so I'm wondering if by setting > > white-space-collapse='false' in the fo:block, docbook-xsl is causing > > FOP to do the right thing? Is it true that white-space-collapse='false' > > implies the same effect as linefeed-treatment='preserve'? > > Gregor, > > This is not a comment on how fop handles the situation. > According to the spec if white-space-collapse="false" then it "Specifies no > special action". > If it is true then it collapses multiple white space char except preserved > linefeeds (if linefeed-treatment='preserve'). > For linefeed-treatment if the value is preserve then it "Specifies no > special action". > > So if FOP does nothing different it will be correct. > > Any other combination may be an entirely different situation. Thanks for the reply. So, does that mean that the entry in src/codegen/foproperties.xml should be edited so it doesn't say ToBeImplemented? If its being handled correctly, then we don't need the message to be printed. If there is some work still to be done before it can be considered completely supported, perhaps its a small enough task that I could figure it out... If nobody else is working on this, I'll go dig into the spec to see where the possibilities are discussed and then crawl through the code to see if I can find the right place(s) to make changes. I've not contributed code before, so pointers would be appreciated. From a little find+grep I see that linefeed-treatment is mentioned only in foproperties.xml and in src/org/apache/fop/fo/flow/Block.java (but it is only in a comment there). I see that white-space-collapse is mentioned in a few places. Regards, -- Gregor _ / \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: linefeed-treatment
On Tue, 07 Aug 2001 17:35:59 Gregor N. Purdy wrote: > Curious: > > I'm using the docbook-xsl-1.14 tools from docbook.sourceforge.net to > convert a DocDook XML file into xsl:fo and then using FOP to convert > that into PDF. I've noticed FOP printing messages like this: > > warning: property - "linefeed-treatment" is not implemented yet. > > it turns out that docbook-xsl is using that attribute on the fo:block > elements it creates out of my DocBook elements. > > Is linefeed-treatment handling on the radar screen? > I'm getting the correct output, so I'm wondering if by setting > white-space-collapse='false' in the fo:block, docbook-xsl is causing > FOP to do the right thing? Is it true that white-space-collapse='false' > implies the same effect as linefeed-treatment='preserve'? Gregor, This is not a comment on how fop handles the situation. According to the spec if white-space-collapse="false" then it "Specifies no special action". If it is true then it collapses multiple white space char except preserved linefeeds (if linefeed-treatment='preserve'). For linefeed-treatment if the value is preserve then it "Specifies no special action". So if FOP does nothing different it will be correct. Any other combination may be an entirely different situation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
linefeed-treatment
Curious: I'm using the docbook-xsl-1.14 tools from docbook.sourceforge.net to convert a DocDook XML file into xsl:fo and then using FOP to convert that into PDF. I've noticed FOP printing messages like this: warning: property - "linefeed-treatment" is not implemented yet. it turns out that docbook-xsl is using that attribute on the fo:block elements it creates out of my DocBook elements. Is linefeed-treatment handling on the radar screen? I'm getting the correct output, so I'm wondering if by setting white-space-collapse='false' in the fo:block, docbook-xsl is causing FOP to do the right thing? Is it true that white-space-collapse='false' implies the same effect as linefeed-treatment='preserve'? Regards, -- Gregor _ / \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc.http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
