Future of some functions in the class KCharsets

[Nicolas Goutte]

On Sunday 03 September 2006 13:40, Thiago Macieira wrote:
> Nicolas Goutte wrote:
> >As the functions are not related to QTextCodec and as the KCharsets
> > class has changed its main purpose since Qt2/KDE2, I intend to move
> > them out in they own class.
> >
> >I propose the name KEntity for that class. (I have chosen the singular
> > form, as there is already a file entities.c which is related.)
>
> Make that KHtmlEntity, since they are HTML-specific (except for < and
> &, which come from XML).

H'm, your comment makes me think that I must check if the code handling 
DocBook, if it uses those functions too. However it seems that there are only 
defined in the DTD in kdelibs/kdoctols/docbook/*/ent/*

(SGML includes many entities. That is why there are in HTML (but only the more 
common ones) and in DocBook. But as XML is simplified SGML, only the very 
necessary ones were kept.)

On the other side, KHtmlEntity could be the right name, as the main purpose is 
for HTML.

>
> >To the third problem: UTF-7
> >KCharsets defines UTF-7 in the list of encodings but Qt does *not*
> > support it. I propose to remove it from the list, especially that the
> > further use of UTF-7 should not be encouraged and UTF-8 should be used
> > instead.
>
> There are still a few places where UTF-7 is used (like the pseudo-UTF-7 in
> IMAP4). But I think kdepim already has its own encoding functions and
> classes to deal with that.

But if IMAP uses UTF-7 and even in a QTextCodec-compatible way, does it need 
to be user-visible, i.e. does a user needs to select "UTF-7" somewhere?

Also the encoding lists returned by KCharsets functions can still be appended. 
(That is what I have done in some of KWord's filters, to add encodings that 
were not defined in KCharsets's lists.)

>
> So I'd go with the removal.

Have a nice day!