Future of some functions in the class KCharsets
nicolasg at snafu.de
Sun Sep 3 13:06:09 BST 2006
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
> >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!
More information about the kde-core-devel