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

List:       koffice
Subject:    Re: Hopeful suggestion for kword
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-04-28 12:30:58
[Download RAW message or body]

On Friday 27 April 2001 13:55, Nicolas Goutte wrote:
> Okay, I have answered to your other mail yesterday, now it is time that I 
> answer also this one.
> 
> 1. XML
> Sorry, but it is not XML that is about separating content from markup. 
> Putting the formating out of markup has been the task of Cascaded Style 
> Sheet, so that a same document (when correctly written) might be displayed 
> on a computer screen, displayed on a mobile phone, printed, rendered into 
> speech, embossed as braille into paper and so on.
> 
> The role of XML was to make a simplier and cheaper to implement version of 
> SGML. And SGML (for example DocBook) is about document structure.

Well, KWord is NOT a CSS renderer. You can keep repeating your love for
XHTML and CSS :), it won't change KWord. The additionnal work involved in
parsing CSS (with the lack of tools for it currently available, unlike
XML which Qt provides full support for), isn't just worth it.

> 2. Searching
> Nobody would expect to be able to search directly across words in any SGML 
> format (for examples, DocBook, HTML or XML formats like AbiWord's), because 
> words can be separated by any inline tag. This has not yet to do anything 
> with formatting, formatting just add more of those "breaks".
> Please take a look at the example of the chapter 2.2 of the CSS2 
> specification http://www.w3.org/TR/REC-CSS2 . This is a XML file and you 
> will not be able to search "his flute" !
> (And even in Rich Text Format, you cannot search like that!)

And ? It's not difficult to search in KWord's XML either....

> 2. "Mixing The Two Design"
> Sorry, here I cannot follow. What is horrible at, for example ((X)HTML + 
> CSS2):
> 
> <h1 class="Heading1">This is a title with <span 
> style="text-decoration:underline">underlined text</span></h1>
> 
> Compare to what would be in a <PARAGRAPH> element in a KWord file to 
> describe the same.

which shows an interesting point.
h1 is one thing, but KWord doesn't have hardcoded style names anymore,
it lets the user define any style, with any properties. If KWord has
to be limited due to the way HTML/CSS works, then we run into trouble.
There are MANY other things where KWord doesn't work the same way as
HTML/CSS. From Counter structures, to alignments, to FootNotes, Variables,
serial letters, etc. etc. A Word Processor goes beyond a web page.

> 3. Structures In KWord
> Structures are not a problem. (X)HTML has the <div> tag that can help you 
> there.

But I still don't see what the problem is with the current scheme either.

> 4. Just Counting Characters
> The problem with "just counting characters" is that XML tools cannot do it, 
> as this cannot be expressed in any way in a DTD.
> When I say XML tools, it also includes other similar tools like Jade.

I see you're trying to change KWord to adapt it to existing tools.
What about adapting (customizing) those tools instead ?

> Additionally you can see in any of KWord's import/export filter how many 
> work this character counting does, even in the ASCII export filter!

... because it doesn't dismiss formatting information, it tries to use it.
A pure ascii export wouldn't need it.

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today

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