pdf-devel
[Top][All Lists]
Advanced

[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).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]