Jjc | 1 Sep 2004 02:38

foto

foto


Attachment (foto.zip): application/octet-stream, 4558 bytes
arnd.beissner | 3 Sep 2004 09:40
Picon

Handling of text-align="justify" when nesting blocks

Editors,

please consider the following inconsistency in the recommendation:

Example:

<fo:block text-align="justify">
TEST TEST TEST TEST ..... ENOUGH TEXT TO FORMAT INTO MULTIPLE LINES 
.... TEST ENDS A. 
<fo:block>
whatever
</fo:block>
TEST TEST TEST TEST ..... ENOUGH TEXT TO FORMAT INTO MULTIPLE LINES 
.... TEST ENDS B.
</fo:block>

Now what would you expect:

Version A:

TEST TEST TEST TEST
TEST ENDS A.
whatever
TEST TEST TEST TEST
TEST ENDS B.

OR

Version B: (second line is justified)

TEST TEST TEST TEST
TEST   ENDS      A.
whatever
TEST TEST TEST TEST
TEST ENDS B.

Common sense would probably say "A":

But, 7.15.9 of the rec says:

The last (or only) line of any block, and any lines in the block ending in 

U+000A, will be aligned in accordance with the "text-align-last"
property value. If such lines are to be justified specify
"text-align-last='justify'".

In the example, line 2 is neither the last nor the only line of a block, 
and it's also not a line ending in U+000A, so it should be justified.

In contrast to this, 7.15.10 (text-align-last) says
(thanks to Luca Furini for the hint):

"Specifies the alignment of the last line-area child of the last
block-area generated and returned by the formatting object, and to any
line-area generated by the formatting object whose following sibling is a
block-area that is not a line-area, and any lines in the block ending in 
U+000A."

If 7.15.9 were worded like 7.15.10, the example would be formatted like
in Version "A", which is probably what the editors intended.

7.15.9 and 7.15.10 now clearly contradict each other, IMO.
My suggestion is to change the cited portion of 7.15.9 to the
following wording:

"The last line-area child of the last block-area generated and returned
by the formatting object, and any line-area generated by the formatting
object whose following sibling is a block-area that is not a line-area,
and any lines in the block ending in U+000A, will be aligned in accordance
with the "text-align-last" property value. If such lines are to be
justified specify "text-align-last='justify'".

Thanks for considering this,

Arnd
--

-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

fredick richard | 17 Sep 2004 03:22

order require


Dear  sales,

                   Its a great opportunity for me to mail u ,i am an international business from new zealand  and my name is smith.
                   with kindly  i will like to order from your store, to my store in  NIGERIA and before i proceed, i will like to
know if you can ship to my store in  NIGERIA  and the issueing of  my payment is by CREDIT CARD.
 i hope to hear from you soon asap .

                                   best regard
                                                                                                                smith

_____________________________________________________________
  Get Your Free Email at http://www.totalmail.com

Joseph, Hinry (C)(STP | 17 Sep 2004 17:30

http://www.w3.org/1999/XSL/Transform download local copy (Urgent)

Liam - they just have setup firewalls in our environment, and we no longer access the http://www.w3.org/1999/XSL/Transform namespace.  Is there a way that our team can download a local copy of version 1.0 of the namespace?  This is rather urgent because it has broken our environments.
 
Thanks in advance for your help,
 
Hinry
uws | 17 Sep 2004 21:38
Picon
Picon
Favicon
Gravatar

http://www.w3.org/1999/XSL/Transform download local copy (Urgent)

På Fri, Sep 17, 2004 at 10:30:52AM -0500, Joseph, Hinry (C)(STP) skrev:
> Liam - they just have setup firewalls in our environment, and we no
> longer access the [1]http://www.w3.org/1999/XSL/Transform namespace.  Is
> there a way that our team can download a local copy of version 1.0 of the
> namespace?  This is rather urgent because it has broken our environments.

Namespace locations are not URL's. The XML specification explicitly states
that there's no need to put a webpage or some other form of content on the
"location" specified, although work is being made to standardize this.

So, you don't need to "download the namespace". All you need is a local copy
of the DTD or schema you're using.

  mvrgr, Wouter

--

-- 
:wq                                                       mail uws <at> xs4all.nl

i'll be your sun coming up :: i'll be your dark days         -- heather nova
Liam Quin | 21 Sep 2004 17:45
Picon
Favicon

http://www.w3.org/1999/XSL/Transform download local copy (Urgent)


On Fri, Sep 17, 2004 at 10:30:52AM -0500, Joseph, Hinry (C)(STP) wrote:
> Liam - they just have setup firewalls in our environment, and we no
> longer access the http://www.w3.org/1999/XSL/Transform namespace.

There's no such thing as "accessing a namespace".  If you are
experiencing difficulties I suggest you contact your local
support group.

*

The W3C Publishes the specifications for XSL.  We do not have resources
to answer basic or introductory questions.

If you believe have found an error in one of our specifications,
or have a comment that might improve them, particularly in the aera
of interoperability, please send a message (*in text* with a clear
Subject) to the comments address given in the Status section of
that specification.

All public comments are considered, and you will receive a reply,
although it sometimes takes several months.

Liam

--

-- 
Liam Quin, W3C XML Activity Lead
http://www.w3.org/People/Quin/

Paul Grosso | 29 Sep 2004 15:40

FW: 1.1 WD Comment on autogenerated property IDs.

Forwarding to xsl-editors.

From: w3c-xsl-fo-sg-request <at> w3.org [mailto:w3c-xsl-fo-sg-request <at> w3.org] On Behalf Of Steve Zilles
Sent: Tuesday, 2004 September 28 20:53
To: Glen Mazza
Cc: w3c-xsl-fo-sg <at> w3.org
Subject: 1.1 WD Comment on autogenerated property IDs.

On Sat, 21 Aug 2004 11:14:02 -0400, Glenn Mazza wrote:

Editors: I previously wrote [1] on the issue of autogenerated property ID's a few months back.  I have an additional comment on this topic and a change to my previous suggestion: A search on <idref> within the 1.1 WD gives only two defined uses of the ID property: 1.) as the internal_destination for an fo:basic-link. 2.) as the ref_id for an fo:page-number-citation. If this is correct, then given that both defined uses for the property ID require the user to have advance knowledge of what the ID value is, the value of subsequently autogenerated ID's for FO's remains unclear.  OTOH, if autogeneration is primarily for internal processing of the document, that would appear to be an implementation detail that doesn't need to be placed in the recommendation.  (FOP, for example, currently does not need such an autogenerated ID, and shouldn't be required to generate one.) ...
Glenn you are correct that the autogenerated ID's are not reachable by any links (either inside or outside the document). In fact, an implementation can ignore these IDs. They were put into the specification to satisfy the following requirements:

1) every property must have an initial value.

2) the "ID" property takes an identifier (string of characters) as its value and that string must be unique in the result tree.

Requirement 1) means that some value must be specified and requirement 2) means that the value cannot be a keyword, such as "none" because that would be a legal ID identifier. Furthermore, the value must be unique in the result tree which eliminates any single initial value.

That lead us to the creation of a random unique identifier that is unique in the result tree. This is effectively equivalent to your "implementation dependent value", but more clearly satisfies the above formal requirements of the specification. Therefore, the Working Group sees no need to make a change in the specification nor is there any need for an implementation to realize these not reachable IDs.

        Steve
=====================================
Steve Zilles
115 Lansberry Court,
Los Gatos, CA 95032-4710
steve <at> zilles.org

Gmane