[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