-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 10 March 2003 18:49, Philip Boutros wrote:
> Hi David
>
> The glyphs associated with Unicode characters are well defined. Code points, like "25A0 (BLACK SQUARE)", exist for all the symbols you describe.
Certainly.
> Given this, is there really a need to add an extra set?
> If KWord chooses a mapping from its generic bullets to Unicode characters
> and supports this mapping on import and export then there would be no data
> loss to and from the open office format.
>
>
> One issue is that there are several things in Unicode that look like a "small circle" but have different code points. Same for squares, arrows, etc.
Exactly, that's the problem. A filter, or another word processor, will never know
if it handles all the possible cases, simply because there are too many
possibilities.
Without starting OO or looking into an existing, can you tell which Unicode
codes it's going to use, for those 8 bullets it offers? I guess not - which means
one would have to do this by a "reverse-engineer" method (save and inspect).
What about the following compromise? The file format isn't changed,
but the documentation for it lists the unicode chars used for those
common bullets. That way a filter can easily know which if()s it has to write
(err I mean switch/case ;).
- --
David FAURE, faure@kde.org, sponsored by TrollTech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
How to write a Makefile.am for KDE/Qt code:
http://developer.kde.org/documentation/other/makefile_am_howto.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+bNd372KcVAmwbhARAqPYAKCzNCFlyBo1yTOGna+8ta6gsOt68ACffaix
8anFeAlr7XqU1MUniNKzA+A=
=RYng
-----END PGP SIGNATURE-----