[gs-devel] Long cmap table in TT font.

Dan Coby dan.coby at artifex.com
Mon Jun 19 10:57:45 PDT 2006


Alex,

Take a look at the lstring, larray, etc. procedures in pdf_base.ps.
These may be useful to you.

Dan


-----Original Message-----
From: gs-devel-bounces at ghostscript.com
[mailto:gs-devel-bounces at ghostscript.com]On Behalf Of Alex Cherepanov
Sent: Monday, June 19, 2006 7:36 AM
To: gs-devel at ghostscript.com
Subject: [gs-devel] Long cmap table in TT font. 


Hi All,

I'm looking into the bug http://bugs.ghostscript.com/show_bug.cgi?id=688688

The font has an extra-long cmap table that doesn't fit into a string,
which is used in the current implementation. An obvious approach would
be to use an array of strings. In this case an access operation
changes to something like:

% get operation for the array of strings. Untested.
/long_get {
   1 index type /stringtype eq
  { get
  }{
    exch //true exch {  % i true ()
       exch pop
       2 copy length % i () i len
       lt {
         exch get //false exit
       } {
         length sub //true
       } ifelse
    } forall {
      % add error handling here
    } if
  } ifelse
} bind def

Running loops in the low level access function is likely to be quite
slow.


Ghostscript also has limited support of .bytestring, a string type free 
of 64k byte limit. Unfortunately, most string operations are not yet
implemented for .bytestring .

Ghostscript was not the 1st PS interpreter to encounter a 64K limit on 
the string size. PostScript 3 introduced reusable streams to
support large blocks of data. The cmap handling code can be re-written
using reusable streams instead of strings.

Does anybody have any comments?

Regards,
Alex Cherepanov


_______________________________________________
gs-devel mailing list
gs-devel at ghostscript.com
http://www.ghostscript.com/mailman/listinfo/gs-devel



More information about the gs-devel mailing list