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: 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
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
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: 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
white-space-treatment property
Team,
I'm having some confusion with the
white-space-treatment property for a
block.(http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#white-space-treatment)
The default value is this property is
ignore-if-surrounding-linefeed, and here is its
definition in the spec: (sorry to torture you all ;-)
Specifies that any character flow object, except for
U+000A (linefeed) characters, whose character is
classified, before any linefeed-treatment handling is
considered, as white space in XML (or any sequence of
such character flow objects) that immediately precedes
or follows a character flow object whose Unicode code
point, before any linefeed-treatment handling is
considered, is U+000A (linefeed), shall be discarded
during the refinement process.
The term *immediately* precedes or follows would
appear to indicate that no more than two whitespace
characters (one before and one after the linefeed)
could be removed from the block. In other words, given
this fo:block:
fo:blockHere is sentence one.{linefeed}
Here is sentence two./fo:block
(with four spaces after one. and the linefeed, and
four leading spaces on the second line.)
The default value of ignore-if-surrounding-linefeed
would appear to resolve this as:
Here is sentence one. {linefeed}
Here is sentence two.
i.e., retaining *three* spaces before and after the
linefeed, as well as the linefeed itself in the text.
This doesn't appear correct. The default value of
whitespace treatment + linefeed treatment (which just
converts the linefeed to a single space) should result
in:
Here is sentence one. Here is sentence two.,
correct?
I'm probably missing something pretty fundamental
here, I just don't know what!
Thanks,
Glen
__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
Re: white-space-treatment property
Look here: Specifies that any character flow object, except for U+000A (linefeed) characters, whose character is classified, before any linefeed-treatment handling is considered, as white space in XML (or any sequence of such character flow objects) The default value of whitespace treatment + linefeed treatment (which just converts the linefeed to a single space) should result in: Here is sentence one. Here is sentence two., It will do so anyway, reagardless of the white-space-treatment, because by default whitespace is collapsed. J.Pietschmann
white-space-collapse property in PageNumber/PageNumberCitation
Question: property white-space-collapse (Spec 7.15.12) is defined within both PageNumber.java and PageNumberCitation.java as an integer, but according to the spec this property is not defined for these two FO's (example: http://www.w3.org/TR/xsl/slice6.html#fo_page-number, scroll down to applicable properties). Am I missing something here--why do we have W-S-C defined for these two? Thanks, Glen __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: white-space-collapse property in PageNumber/PageNumberCitation
Glen Mazza wrote: Question: property white-space-collapse (Spec 7.15.12) is defined within both PageNumber.java and PageNumberCitation.java as an integer, but according to the spec this property is not defined for these two FO's (example: http://www.w3.org/TR/xsl/slice6.html#fo_page-number, scroll down to applicable properties). Am I missing something here--why do we have W-S-C defined for these two? Copy+paste, I think, and a lot of inertia. You've got hyphenation props on Character as well as aural props and other stuff all over the place. Apropos aural properties: anyone with enough time at hand to make a voice renderer based on FreeTTS? :-) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: white-space-collapse property in PageNumber/PageNumberCitation
J.Pietschmann wrote: Copy+paste Well, actually the FO classes were boostrapped by generating the Java classes from an XML file derived from a draft of the spec itself. Note: draft. Probably also some errors crept in during the process... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: white-space-collapse property in PageNumber/PageNumberCitation
I guess we have some cleanup to do--I'll take a look at some of the FO's this weekend and report back to the team on property-removals we may need. The interesting FO's will be those which are actually utilizing invalid properties in their processing logic--hopefully there won't be many! Glen --- J.Pietschmann [EMAIL PROTECTED] wrote: J.Pietschmann wrote: Copy+paste Well, actually the FO classes were boostrapped by generating the Java classes from an XML file derived from a draft of the spec itself. Note: draft. Probably also some errors crept in during the process... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: white-space-collapse property in PageNumber/PageNumberCitation
J.Pietschmann wrote: Apropos aural properties: anyone with enough time at hand to make a voice renderer based on FreeTTS? :-) Actually, I have a strong interest in TTS. We are trying to work it into our proofreading cycle, so the computer reads the text out loud to a proofreader who is looking at an original document (we convert old documents to text). Maybe someday ... after fonts ... after layout ... after layout strategy ... after API ... Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: white-space line-ending changes
J.Pietschmann wrote:
I had the same problem when I commited for the first time. As far as I
found out, you have to be subscribed to fop-cvs mail list using your
*apache email address* + first message may be postponed a little bit
by moderator (nobody knows who is it though :).
BTW I'm subscribed to fop-cvs with my spam-filtered address and have no
problems.
But your commit messages nevertheless are sent only from [EMAIL PROTECTED]
My conclusion was based on a quick analysis of $CVSROOT/CVSROOT/loginfo file
at cvs.apache.org. This one usually defines an action being performed on each
commit into a cvs repository. Our one runs $CVSROOT/CVSROOT/log_accum.pl
script, which in turn (I should admit I'm not perl expert) actually
consolidates message and sends it to the mail list through sendmail program
from $ENV{'USER'}@apache.org address.
And if commit messages are always sent from $ENV{'USER'}@apache.org address,
this one should be subscribed to the list.
May be there is another door though.
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: white-space line-ending changes
J.Pietschmann wrote: Well, the cvs commit command has to be invoked from within the checked out tree. Otherwise no commit message is mailed at all. For example $pwd $CWD is /usr/pietsch/gnu/fop $cvs checkout xml-fop $... Change to xml-fop before committing at this place. $ cd xml-fop $ cvs commit No parameters necessary. If the command asks you for a module to commit, or for logging in again, you made something wrong. BTW I'm subscribed to fop-cvs with my spam-filtered address and have no problems. The commit was working, and I could even see that it was trying to create a mail message -- it just wasn't getting mailed. I followed Oleg's suggestion of switching my subscription to fop-cvs to my apache.org mailing address that seems to have fixed the problem. I am not sure how to reconcile that with your experience -- maybe it just has to be touched maybe there is more than one way to do that. I guess I don't care enough to find out. Thank you both for your help. BTW, it is good to have you back. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
white-space line-ending changes
I have committed some changes to the trunk that clean up 1) tabs, 2) spaces at end of lines, and 3) CR/LF line endings. These touched quite a few files, mostly doc, but should have no effect other than to minimize future spurious deltas. I do not see the auto mail messages coming from CVS related to these changes -- perhaps it is smart enough to know that these are innocuous, or perhaps there is something wrong with my mail account. At any rate, I wanted you to know what was going on when you see the files being updated. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: white-space line-ending changes
Victor Mote wrote: I have committed some changes to the trunk that clean up 1) tabs, 2) spaces at end of lines, and 3) CR/LF line endings. These touched quite a few files, mostly doc, but should have no effect other than to minimize future spurious deltas. I do not see the auto mail messages coming from CVS related to these changes -- perhaps it is smart enough to know that these are innocuous, or perhaps there is something wrong with my mail account. I had the same problem when I commited for the first time. As far as I found out, you have to be subscribed to fop-cvs mail list using your *apache email address* + first message may be postponed a little bit by moderator (nobody knows who is it though :). -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4171] - white-space-collapse=false does not work
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=4171. 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=4171 white-space-collapse=false does not work [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-04-23 15:21 --- An XSL style sheet is not the same as an XSLFO source. By specification, text nodes containing only whitespace are stripped from the style sheet unless they are in an xsl:text element (the XML source is another matter). This means, the whitespace text node child of the fo:inline in question is completely stripped, and the fo:inline ends up empty in the transformation result. This can be easily verified by running the transformation standalone. If white space from a style sheet (not the XML source) should be passed to the result, use either xsl:text xsl:text /xsl:text or xml:space=preserve fo:inline white-space-collapse=false xml:space=preserve /fo:inline Only the former is really guaranteed to work. (There are processors where the latter doesn't work by design) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: white-space
Title: RE: white-space u can put #160; ( # 1 6 0 ;) this will work. rgds, Rabi. -Original Message- From: Joerg Pietschmann [SMTP:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 5:37 PM To: FOP Dev Subject: Re: white-space I need white space between fields, how do I do that? ... xsl:value-of select=city /, !--I NEED A WHITE SPACE HERE-- xsl:value-of select=state / !--I NEED WHITE SPACE The canonical solution is to use xsl:text xsl:value-of select=city / xsl:text, /xsl:text xsl:value-of select=state / xsl:text /xsl:text xsl:value-of select=zipcode / This is actually a XSLT questio, not directly related to FOP. Read the XSLT spec http://www.w3.org/TR/xslt or any of the good books for more about whitespace handling during an XSL transformation. XSLFO has some specialities as well. HTH J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
white-space
I need white space between fields, how do I do that? fo:block font-size=10pt font-weight=bold font-family=sans-serif text-indent=10pt xsl:value-of select=city /, !--I NEED A WHITE SPACE HERE-- xsl:value-of select=state / !--I NEED WHITE SPACE HERE-- xsl:value-of select=zipcode /!--I NEED WHITE SPACE HERE-- /fo:block So that the address will look like this Austin, TX 78758 instead of, Austin,TX78758 Thanks in advance for your help! -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: white-space
You can use the concat function, just to put a space after a value. Just like this: xsl:value-of select=concat(city,', ')/ xsl:value-of select=concat(state,' ')/ xsl:value-of select=zipcode/ -Oorspronkelijk bericht- Van: Gus Delgado [mailto:[EMAIL PROTECTED]] Verzonden: donderdag 31 januari 2002 15:11 Aan: [EMAIL PROTECTED] Onderwerp: white-space I need white space between fields, how do I do that? fo:block font-size=10pt font-weight=bold font-family=sans-serif text-indent=10pt xsl:value-of select=city /, !--I NEED A WHITE SPACE HERE-- xsl:value-of select=state / !--I NEED WHITE SPACE HERE-- xsl:value-of select=zipcode /!--I NEED WHITE SPACE HERE-- /fo:block So that the address will look like this Austin, TX 78758 instead of, Austin,TX78758 Thanks in advance for your help! -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4171] New: - white-space-collapse=false does not work
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=4171. 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=4171 white-space-collapse=false does not work Summary: white-space-collapse=false does not work Product: Fop Version: all Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I create a FO document with fo:inline white-space-collapse=false /fo:inline I see that in my final document I can get two spaces to separate certain items. But when I change the document to a xsl stylesheet with FO I stops working. Here's a style sheet in where it fails! When I chang it back to an FO document (strip first two and last two lines from the file it works as aspected!) ?xml version=1.0 encoding=iso-8859-1? xsl:stylesheet version=1.0 xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:output indent=yes / xsl:template match=/ fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=my-page page-height=297mm page-width=210mm margin-top=1.17cm margin-bottom=2.54cm margin-left=1.9cm margin-right=1.9cm fo:region-body / /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-name=my-page fo:flow flow-name=xsl-region-body fo:block text-align=left font-size=10pt line-height=10pt This is a test.fo:inline white-space- collapse=false /fo:inlineThis is anotherone! /fo:block /fo:flow /fo:page-sequence /fo:root /xsl:template /xsl:stylesheet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Bug 4171] New: - white-space-collapse=false does not work
At 10:25 15-10-2001, [EMAIL PROTECTED] wrote: When I create a FO document with fo:inline white-space-collapse=false /fo:inline I see that in my final document I can get two spaces to separate certain items. But when I change the document to a xsl stylesheet with FO I stops working. No - it's working correctly, but there's a point about XSLT that you're missing. fo:block text-align=left font-size=10pt line-height=10pt This is a test.fo:inline white-space- collapse=false /fo:inlineThis is anotherone! /fo:block XSLT has whitespace stripping rules. By default, any text node in the stylesheet that consists entirely of whitespace is stripped, unless it is a child of an xsl:text element. In this case, the content of the fo:inline is only whitespace, so it is stripped. If you run this XSLT on its own, you will see that the output document has fo:inline white-space-collapse=false/fo:inline in it. See ยง3.4 of XSLT. In your stylesheet, do something like fo:inline white-space-collapse=false xsl:text/xsl:text /fo:inline -Chris -- Christopher R. Maden, Principal Consultant, HMM Consulting Int'l, Inc. DTDs/schemas - conversion - ebooks - publishing - Web - B2B - training URL: http://www.hmmci.com/ URL: http://crism.maden.org/consulting/ PGP Fingerprint: BBA6 4085 DED0 E176 D6D4 5DFC AC52 F825 AFEC 58DA - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
