Bug 689041

Although v. 8.54 is the last release, it is quite old.
Many bugs have been fixed in the current development release.
You can get it with the following command:
svn co http://svn.ghostscript.com:8080/ghostscript/trunk/gs

If you reproduce the problem in the current development version
we need a sample file to debug it.

Created attachment 2679 [details]
Example PS File , Converted PDF File (When Fontmap.GS is used) , Converted PDF File (when Fontmap.kanji) is used

Hi,
I have attached the example post script and converted PDF files (when using
Fontmap.GS and Fontmap.kanji). As you can see from these file eiether i am
getting Japanese Font or English Font. But not both together.
When i am using a 6.01 binary ps2pdf . This works fine.
Kindly let me know whether i should try some other make options.
Regards
Deb

Hi,
As suggested i have download the tar file of revision 7600 and trying ton 
install it on Unix system.

While running autogen.sh it exits giving an error.

The Message is
--------------------------------------------------------------------
Generating configuration files for ghostscript, please wait....
  creating links to configuration sources
  running autoconf
autoconf: configure.in: No such file or directory
I am going to run ./configure with no arguments - if you wish 
to pass any to it, please specify them on the ./autogen.sh command line.
./autogen.sh: ./configure: not found
----------------------------------------------------------------------

Please fix this.

Regards
Deb

Hi,
We dont't have CVS here so i downloaded the tar file form 
http://cvs.ghostscript.com/cgi-bin/viewcvs.cgi/ghostscript/trunk/gs/
(Revision 7600) . I have untrarred the file in Unix machine and trying to build 
it. Executing the ./autogen.csh gives problems as given in my earlier post. Can 
you please let me know how i can use Japanese Fonts Correcttly.

Regards
Deb

Please re-attach the PS file uncompressed.
The PS file provided in the comment #2 is damaged - it starts with many binary
0 overwriting the file content.

Regarding the autogen.sh problems, it looks like your autoconf is too old.
Ghostscript has configure.ac instead of configure.in . 

Created attachment 2685 [details]
Example Post Script File

Created attachment 2686 [details]
PDF file Genearted with Fontmap.GS in ../share/lib Directory

Created attachment 2687 [details]
PDF file Genearted with Fontmap.kanji in ../share/lib Directory

Hi,
Please find the new Example Post Script file , PDF file generated with 
Fontmap.GS ( You can see only English charactres here) , PDF file generated 
when Fontmap.kanji is used( you can see the kanji characters but english is 
junk). Please let me if how make it work with 8.54. We have binaries of 6.01 
and it works fine there.
I can upgrade the autoconf as it is shared and used by many project teams. So i 
have work with the release version of 8.54 i guess(which i have built already 
but giving the above problem).
Kindly let me know the solution of Japanese Fonts at the earliest. I am stuck 
up in the Prohect due to this.
Many many thanks in advance.
Deb

Hi,

Any updates regarding this?

Regards
Deb

Hi,
Raised this bug almost a month ago. Can you kindly clarify whether somebody is 
looking at the issue or not?
Kindly note that i am not able to proceed with my work without the resolution 
of this.
Regards
Deb

First, I thinks it's normal that japanese text does not appear when 
there are no Japanese fonts installed.

Secondly, the problem appears on Windows too if installing and using 
the fonts in gs6.0.kanji.tar (with the appropriate lines added to the 
fontmap).

Next, I suspect the Windows version worked for the original reporter 
because he had the Japanese TrueType fonts/collections from MS 
installed, and AFAIK the GS installer looks for Far-Eastern fonts and 
creates a suitable cidfontmap (not checked, I don't use the installer).

The files in gs6.0.kanji.tar create 2 big Type 0 fonts with many 
descendants of various types: some Type 3, some Type 1 and even Type 0
that further have many Type 3 descendents. That being said, I found 
this bug to be related to Ghostscript's pdfwrite driver, not to the 
fonts, and to be one of the following duplicates:

    Bug #688639 "pdfwrite: a composite font with a Type 3 descendent 
                 and FMapType 2"
    Bug #688760 "ps2pdf loses text in postscript figure when 
                 converted to pdf"
    Bug #688954 "Text disappears when converting some ps files
                 with ps2pdf"
    Bug #689001 "Characters lost converting PS to PDF"
    Bug #689041 "Japanese Font Display Problem is ps2pdf"
    Bug #689105 "Invalid fonts error during converting from PS to PDF"

For a fix, please see bug #688639 comment #13. I suggest to close 
this bug as a duplicate of bug #688639.

Hi,
I compiled the source code with patches and it works fine now. But have very 
big sized PS files. Now after the patch the PDF size increases by 20-25% and 
the conversion time is also has increased considerably.
Any suggestions (pdfopt and -dOptimize=true actually increases the size of the 
doc)

Regards
Deb

Created attachment 2834 [details]
Attachment #2685 [details] modified for comparing the performance.

Unpached version skips much of the contents. An increase in conversion 
time and file size is normal for the simple fact that there is more 
content processed - similar to a larger input file needing more time 
to convert and producing a larger output PDF.

pdfopt.ps is not for optimizing the PDF in terms of size, it is for 
"linearizing" it. As you remarked, the PDF size actually increases a 
bit because of the added (and needed) "hint tables".

I thought the Distiller "Optimize" parameter is not implemented, so it 
makes no difference (but maybe I'm wrong). In any case, it's connected 
to the same "linearized PDF" thing.

I actually found a way to verify if performance decreases. Attached is 
a copy of the sample file with "show" strings edited to remove all chars 
that unpached GS ignores; so, both patched and unpached GS process the 
same amount of contents. Then, I concatenated 50 copies of it and passed 
the result to both patched and unpatched GS. The PDFs obtained were 
identical (except creation date/time, metadata, and document ID), and 
the patched version was insignificantly faster (a 0.6 sec difference in 
its favor, for a conversion time of 131 sec). So no, the patch does 
not affect the performance.

As to the PDF size: yes, I find it excessive, but I tend to blame the 
way the PostScript file is written and the fonts. I do not exclude a 
problem with GS either. However, this is not related to the current bug. 
For general advice on optimizing PostScript, try comp.lang.postscript; 
also, the folks on comp.fonts may have an idea if anything can be done.

*** This bug has been marked as a duplicate of 688639 ***