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

List:       koffice-devel
Subject:    Re: PATCH: kspread html export
From:       Nicolas Goutte <nicog () snafu ! de>
Date:       2001-07-30 16:40:01
[Download RAW message or body]

On Monday, 30. July 2001 01:25, David Faure wrote:
> On Monday 30 July 2001 02:17, Nicolas Goutte wrote:
> > On Sunday, 29. July 2001 21:47, David Faure wrote:
> > > On Sunday 29 July 2001 22:32, Nicolas Goutte wrote:
> > > > > -don't claim utf-8, because it isn't, at least with my tests?!
> > > >
> > > > Yes, this is KDE Bug #27882 "KSpread's HTML Export: wrong charset
> > > > used or declared" ( http://bugs.kde.org/db/27/27882.html )
> > > >
> > > > I had hoped that it would be solved the other way around, i.e. that
> > > > the filter exports in UTF-8 as KWord's HTML export filter, but I have
> > > > never got an answer to my bug report. :-(
> > >
> > > Exporting UTF-8 leads to a very ugly result if the user doesn't have a
> > > unicode font. I'm afraid the only option is to implement a filter
> > > dialog that has a combobox with the charsets, to let the user choose
> > > which charset he wants to use when exporting.
> >
> > Using non-Unicode-encoding is more complicate than just a choice.
> >
> > You have to filter out characters that are not in this (non-Unicode-)
> > encoding and transform them in numeric character references (for example
> > &#160; .) And KSpread's HTML filter does not do this and therefore does
> > not keep characters that are out of the encoding!
>
> Obviously if someone mixes encodings he should select UTF8.
> I was talking about the (much more common) case where there's a single
> encoding in the document. In that case you can simply create a QTextCodec,
> and use it to convert the text. No problem there.

Okay, one question: do you think that KWord's HTML filter exporting in 
local encoding and KSpread's one exporting in UTF-8 are problems to solve for 
KOffice 1.1 or to solve for a later version.

The problem I have now is that I have tried 
QTextCodec::codecForLocale()->name() and I have found out that it does not 
give the right charset names (for example "ISO 8859-1" instead of 
"ISO-8859-1" and it is even worse for asiatic charsets.) I do not think that 
it is a QT bug, I think more that it was never thought to be used in this way.

(See http://www.iana.org/assignments/character-sets for the list of charsets 
and their official names.)

The problem of not being able to write the meta tag
<meta http-equiv="Content-Type" content="text/html; charset=????">
is that the exported HTML file is not usable internationally (or even worse 
through Internet where it might be handled as an ISO-8859-1 file.)

Have a nice day/evening/night!

_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel

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