[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: shift+enter in kword
From:       Nicolas Goutte <nicog () snafu ! de>
Date:       2002-02-28 22:59:37
[Download RAW message or body]

On Thursday 28 February 2002 22:34, Thomas Zander wrote:
> On Thu, Feb 28, 2002 at 10:02:09PM +0100, Nicolas Goutte wrote:
> > On Wednesday 27 February 2002 21:10, Krister Wicksell Eriksson wrote:
> > > Hi
> > >
> > > On Wednesday 27 February 2002 20:53, Nicolas Goutte wrote:
> > > > Thank you for your work!
> > > >
> > > > If I have understood your code well, you use 0x0b as forced line
> > > > break.
> > > >
> > > > Could you tell why you have prefer 0x0b to something else like 0x0a
> > > > (LINE FEED)?
> > >
> > > 0x0b is used by winword so it now works when importing doc-files. I
> > > think 0x0b is a vertical tab.
> > >
> > > > And by the way: you cannot have 0x0b in XML.
> > >
> > > What is the best way to fix this?
> >
> > I am not sure how. (I am just talking about the file format, not the
> > internal representation in KWord/kotext)
> >
> > The easiest would be probably to use 0x0a, but we must be careful that
> > QDomDocument::setContent does not eat it, especially at the start or at
> > the end of a paragraph (In theory/SGML, at start it belongs to the
> > opening tag and at end to the closing tag.)
>

> In XML everything between an open and a close tag will be used. We encode

That is already wrong. For QDomDocument::setContent:
<tag> </tag> 
is the same as
<tag/>

(The white space is lost! A line feed is also a white space. And yes, it is 
allowed.)

> in utf-8 which means that we don't have a limit on the byte value we can
> use. so your clame is nonsense.

I do not see where UTF-8 has something to do with it!

> The 0xa0 char (which is not encoded except for the utf-8 default way) works
> quite well.. (Is used for non breaking space since a week or so, so maybe
> you want to use that in the filters :)

0xa0 is not a white space, so I do not see where the problem is!

And if you are talking about 0x0b, no it is not allowed, because section 2.2. 
of the XML Recommendation specifies which Unicode (not only UTF-8) characters 
are allowed.

>
> > There is also the character 0x2028 (line separator). It has been declared
> > as "not suitable" for XML ( http://www.w3.org/TR/unicode-xml/ .) However
> > the recommendation does not apply "for blind data transport or similar
> > cases." Are we in such a case?
>
> w3 does not define the XML standard; you mix them up quite a lot. They

No? Who then? Please look at the XML Recommendation:
http://www.w3.org/TR/REC-xml

> define the standard that uses XML for hypertext layout. In other words
> XHTML. Read www.xml.com for more info on XML.

I think that you have misunderstood many things!

xml.com also tells that W3C defines XML:
http://www.xml.com/pub/a/98/10/guide1.html#AEN84

>
> > So may be that we only have the choice of using a <FORMAT> element with a
> > new
>
> No need; its not markup either, well is it :)

We'll see!

Have a nice day/evening/night!
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]