[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[pdf-devel] Re: Proposal of API for the Encoded Text module
From: |
jemarch |
Subject: |
[pdf-devel] Re: Proposal of API for the Encoded Text module |
Date: |
Mon, 28 Jan 2008 16:17:48 +0100 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.0.93 (x86_64-unknown-linux-gnu) MULE/5.0 (SAKAKI) |
Find attached my changes to the proposed API for the Encoded Text
module. It's a diff to the gnupdf.texi file.
Please patch gnupdf.texi with the new API. Dont forget to include a
Changelog entry.
Some comments on the changes:
- Host encoding management will probably need a second round. We will
need to clearly determine which OS don't have support for iconv
(excluding Windows OSs, which have their specific way of handling host
encodings).
Read below about http://gnupdf.org/Portability
- Regarding the issue of the `best encoding' to encode a given character
string, I really think that UTF-8 could be the default best encoding for
all of those OS supporting iconv (GNU/Linux, Unix, Mac OS X...) and even
for Windows OSs (AFAIK, UTF-8 is available in all modern Windows
versions... should we give support for older versions?).
What do you call a "modern windows version"? Could you be more
specific?
UTF-8, in fact, is one of the encoding conversions which will be
built-in in the library.
I agree in that UTF-8 should be considered the "best encoding" if it
is supported by the underlying platform.
- Maybe we should really decide which will be the full list of supported
OS (and version of OS, if needed), and not think it during the
development phase.
I agree. See
http://lists.gnu.org/archive/html/pdf-devel/2008-01/msg00003.html
This will help not only to determine the specific OS-dependent
functions for host encoding support (determine which OS don't
handle UTF-8, for example), but also to determine platforms with a
lack of some required feature (e.g. 64bit integers, discussed in
another thread). I could start a new page in the Wiki with this
issue.
There is a little draft on portability in
http://gnupdf.org/Portability We could summary portability issues in
that page (availability of iconv, 64-bit integers, etc).