Re: Suppression of leading space
On Mon, Dec 22, 2003 at 10:38:20PM +0100, Finn Bock wrote: > [J.Pietschmann] > > >>>Anybody dares to interpret how the followung is rendered? > >>> > >>> foo > >>>>>>font-site="15pt">bar > >>>I think this should generate two spaces between "foo" and "bar". > > [Andreas L. Delmelle] > > >>One in 10pt, the other 15pt, or 2 spaces of 20pt? > > [Simon Pepping] > > >I would think one space before foo according to the characteristics of > >the 20pt font and bgcolor red, > > I would have guessed, based on Joerg's previous answer, that the > red-20pt space is suppressed because it follows right after a line-break. This is a comment in layoutmgr.LineLayoutManager.getNextBreakPoss: /* If first BP in this line but line is not first in this * LM and previous line end decision was not forced (LINEFEED), * then set the SUPPRESS_LEADING_SPACE flag. */ Why are there those two exceptions to the suppression of leading space? For example, in this fo fragment the leading space is not suppressed: Some text. Regards, Simon -- Simon Pepping email: [EMAIL PROTECTED] home page: http://www.leverkruid.nl
Re: Suppression of leading space
On Mon, Dec 22, 2003 at 10:38:20PM +0100, Finn Bock wrote: > [J.Pietschmann] > > >>>Anybody dares to interpret how the followung is rendered? > >>> > >>> foo > >>>>>>font-site="15pt">bar > >>>I think this should generate two spaces between "foo" and "bar". > > [Andreas L. Delmelle] > > >>One in 10pt, the other 15pt, or 2 spaces of 20pt? > > [Simon Pepping] > > >I would think one space before foo according to the characteristics of > >the 20pt font and bgcolor red, > > I would have guessed, based on Joerg's previous answer, that the > red-20pt space is suppressed because it follows right after a line-break. I agree, that was an error. Regards, Simon -- Simon Pepping email: [EMAIL PROTECTED] home page: http://www.leverkruid.nl
Re: Suppression of leading space
[J.Pietschmann] Anybody dares to interpret how the followung is rendered? foo bar I think this should generate two spaces between "foo" and "bar". [Andreas L. Delmelle] One in 10pt, the other 15pt, or 2 spaces of 20pt? [Simon Pepping] I would think one space before foo according to the characteristics of the 20pt font and bgcolor red, I would have guessed, based on Joerg's previous answer, that the red-20pt space is suppressed because it follows right after a line-break. regards, finn
RE: Suppression of leading space
> -Original Message- > From: J.Pietschmann [mailto:[EMAIL PROTECTED] > The space constraints probably (hopefully )only applies to > space specifiers on the FOs itself, i.e if I had written > ... > Space characters ought to be another matter. > Try: > > foo > font-size="15pt"> bar > Arghh! First hadn't even noticed the lf after foo... Should it make a difference whether you write: sth or sth or sth Doesn't that depend ... ? (I'm trying to see on what exactly) Using the default values for the related properties (see Finn's OP), space would *always* remain for the latter two cases. Now, don't know for sure what's considered to be best practice, but maybe the only way to really 'solve' the original issue, would be at the FO level. Just advise everyone to use LF rather in the markup itself (like in your example, the second fo:inline). So if, in the last case here above, one *really* needs to avoid trailing and leading spaces, one could rearrange it like (most extreme case) : sth or someverylongphraserunningthroughtotheendofthepagewhichiseemtobeunabletoachi eveatthemoment< /fo:inline> So, in short, no LF between > and the start of the content, nor between the end of the content and <. Perfectly admitted. Cheers, Andreas
Re: Suppression of leading space
Simon Pepping wrote: I see no space in the bar inline. Dumb luck :-). Try: foo bar J.Pietschmann
Re: Suppression of leading space
On Fri, Dec 19, 2003 at 07:11:57PM +0100, Andreas L. Delmelle wrote: > > -Original Message- > > From: J.Pietschmann [mailto:[EMAIL PROTECTED] > > > > > Anybody dares to interpret how the followung is rendered? > > > > foo > > > font-site="15pt">bar > > I think this should generate two spaces between "foo" and "bar". > > > > One in 10pt, the other 15pt, or 2 spaces of 20pt? I would think one space before foo according to the characteristics of the 20pt font and bgcolor red, and one after foo according to the characteristics of the 10pt font and bgcolor blue. I see no space in the bar inline. Regards, Simon Pepping -- Simon Pepping email: [EMAIL PROTECTED] home page: http://www.leverkruid.nl
Re: Suppression of leading space
Andreas L. Delmelle wrote: I think this should generate two spaces between "foo" and "bar". One in 10pt, the other 15pt, or 2 spaces of 20pt? Yeah, I deliberately avoided this part of the answer... So, it would depend on the space-specifiers, which are in this case unspecified (no borders, no padding, only background --hmm, should that have an influence? the font-size would IMHO only have an effect in the bp direction, depending on the alignment-baseline) So defaults to 0pt (not being inherited by default) The space constraints probably (hopefully )only applies to space specifiers on the FOs itself, i.e if I had written ... Space characters ought to be another matter. That's really a dilemma: you can get rid of most control characters with FO markup, especially VT, LF and all that, but there is no way to get rid of spaces. Because of text-align="justify". Unless leader expansion is better defined. J.Pietschmann
RE: Suppression of leading space
> -Original Message- > From: J.Pietschmann [mailto:[EMAIL PROTECTED] > > Anybody dares to interpret how the followung is rendered? > > foo > font-site="15pt">bar > I think this should generate two spaces between "foo" and "bar". > One in 10pt, the other 15pt, or 2 spaces of 20pt? This is the closest in the spec I could find (so far) : [4.6.1 Stacked Inline Areas] For a parent area P whose children are inline-areas, P is defined to be properly stacked if ... 2. For each pair of normal areas I and I' in the subtree below P, if I and I' have an inline-stacking constraint S, then the distance between the adjacent edges of I and I' is consistent with the constraint imposed by the resolved values of the space-specifiers in S. [a little further up 4.2.5 Stacking Constraints] Inline-stacking constraints A and B have an inline-stacking constraint S if ... 3 a. both A and B are inline-areas, B is the next normal sibling area of A, and S is the sequence consisting of the space-end of A and the space-start of B So, it would depend on the space-specifiers, which are in this case unspecified (no borders, no padding, only background --hmm, should that have an influence? the font-size would IMHO only have an effect in the bp direction, depending on the alignment-baseline) So defaults to 0pt (not being inherited by default) Cheers, Andreas
Re: Suppression of leading space
Finn Bock wrote: I was taking a look at the issue where the text in a fo:block has a leading space added. I thought that by default, the initial spaces and LFs for such a block should be suppressed, but I can't quite find the place in the spec where it is defined. It is not explicitely spelled out anywheree. The common interpretation is that 1. spaces are suppressed around line *breaks* (not line feed characters) for the default value of white-space-treatment 2. the start and end of a block are considered to constitute line breaks Specifically 1 means you don't get underlined spaces at the end of a line. If the following foo bar wraps after foo (i.e. there is a line break) the space is suppressed and you don't get foo_ bar (with underlined "foo" and "bar") but foo bar (with underlined "foo" and "bar"). Before you ask the other obvious question: foo bar is rendered as foo _bar (with an underlined "bar"). There is a single non-underlined and a single underlined space between the two (subject to space adjustment). Consecutive spaces are *not* collapsed if they are "marked" differently (different text decoration and perhaps different background etc.) This isn't in the published spec, and unfortunately I couldn't find it in the errata either, however, it is part of the spec anyway, according to some w3 list members. Anybody dares to interpret how the followung is rendered? foo bar I think this should generate two spaces between "foo" and "bar". J.Pietschmann
RE: Suppression of leading space
> -Original Message- > From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] > > In this case, there will never remain a single space as the result of the > second step. > Which would, of course be a problem in case the space resulting from the linefeed *does* need to be preserved... (didn't quite think of that) Cheers, Andreas
RE: Suppression of leading space
> -Original Message- > From: Finn Bock [mailto:[EMAIL PROTECTED] > > > , the text contains: > > 0x0a 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x54 0x68 0x69 0x73 ... > > the spaces surrounding the LF should be ignores: > > 0x0a 0x54 0x68 0x69 0x73 ... > > and the linefeed turned into a space: > > 0x20 0x54 0x68 0x69 0x73 ... > > and last, two or more consecutive spaces removed: > > 0x20 0x54 0x68 0x69 0x73 ... > > which is exactly what HEAD does! > > But surely that can't be right. I must be missing or misreading something. > Depends on what is being meant by 'removal' in the last step above, and 'ignoring' in the first...? Juggling a bit, I think the only way to achieve the desired result is to 'replace' spaces surrounded by a LF by one space, then perform the steps : - two, or more consecutive spaces 'ignored': 0x0a 0x20 0x54 ... - turn the linefeed into a space 0x20 0x20 0x54 ... - consecutive spaces 'removed' 0x54 ... In this case, there will never remain a single space as the result of the second step. Hope this gets you on track! Cheers, Andreas