Bug 692240

Summary: gs9.* gets "Error: /invalidfont in definefont", OK in gs 8.7*
Product: Ghostscript Reporter: William Bader <williambader>
Component: Font APIAssignee: Chris Liddell (chrisl) <chris.liddell>
Status: RESOLVED FIXED    
Severity: normal CC: chris.liddell, williambader
Priority: P4    
Version: 9.02   
Hardware: PC   
OS: Linux   
Customer: Word Size: ---
Attachments: Sample file to show the problem

Description William Bader 2011-05-28 02:00:21 UTC
Created attachment 7544 [details]
Sample file to show the problem

The attached file works fine in gs 8.70 and 8.71 but gets an error in gs 9.00, 9.01 and 9.02.

Impact is the name of a Type1 font embedded in the file and the error is an invalid font in definefont, so this might be a font problem in gs.

$ gs elp-cpag-gs902bug-27may11.ps 
GPL Ghostscript 9.02 (2011-03-30)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /invalidfont in definefont
Operand stack:
   Impact   --dict:12/20(L)--   Font
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1894   1   3   %oparray_pop   1893   1   3   %oparray_pop   --nostringval--   1877   1   3   %oparray_pop   1771   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   1762   2   5   %oparray_pop   --nostringval--   --nostringval--   1850   2   6   %oparray_pop
Dictionary stack:
   --dict:1151/1684(ro)(G)--   --dict:0/20(G)--   --dict:82/200(L)--   --dict:44/64(L)--   --dict:252/300(L)--   --dict:1151/1684(ro)(G)--
Current allocation mode is local
Last OS error: 2
GPL Ghostscript 9.02: Unrecoverable error, exit code 1
Comment 1 Chris Liddell (chrisl) 2011-05-28 08:02:08 UTC
The font is genuinely invalid as it contains:
/FontBBox {0 0 00} readonly def

This is clearly wrong as it parses out to three values, and bounding box must be four values.

Personally, I think throwing an invalidfont error when interpreting an *invalid font* is a good thing! But I also recognise this change in behaviour is not necessarily desirable from a user's point of view.

So, I've changed the new font code to gracefully handle this case.

Commit: 94f1a552f75647f142b85e5f30c075c19dde0084

Can be seen here:
http://tinyurl.com/3gwl329


I would strongly urge you to report the broken font to the font vendor (although as there is no copyright information in the font, I'm more than a little dubious about the heritage of the font!).
Comment 2 William Bader 2011-05-28 10:44:41 UTC
Thanks! That fixed the problem.  The EPS came from an outside source.  I'll see if someone can track them down.  The EPS printed on a laser printer and on the image setter, so adobe rips might also have a similar hack read malformed /FontBBox entries.
Comment 3 Chris Liddell (chrisl) 2011-05-28 11:17:42 UTC
I had a closer look at the font, and with no copyright and no hinting at all, I suspect it's some kind of custom font, so on reflection, it's probably not worth spending much time on.

The %%Creator comment says "Corel Postscript Engine", so at most, maybe chuck a bug report at Corel for them to ignore!

Thanks for confirming the fix, though.
Comment 4 William Bader 2011-05-30 14:41:21 UTC
Thanks again.
By the way, has anyone reported problems with gsromfs1.c?
I did a new ghostscript build with the patch.
On most of my build systems, gsromfs1.c compiles in a few minutes.
On my Solaris system, which doesn't have that much RAM, gcc sometimes runs out of memory if any large applications are running.
On one of my build systems, a 1.6 GHz Pentium 4 with 512 MB RAM, Red Hat Linux 9 (from 2003), and gcc-4.6.0, it took about 10 hours.  Nothing else was running at the time.  When I checked on it after a few hours, gcc had about 110 MB of RAM and a lot of cpu, and it didn't look like it was swapping.
The gs9.01 build took about 1.5 hours.
I have the results of "ls -lt obj | head" for gs9.02.
William

-rw-rw-rw-    1 william  users       16601 May 30 09:08 ldt.tr
-rw-rw-rw-    1 william  users     7866636 May 30 09:08 gsromfs1.o
-rw-rw-rw-    1 william  users    22184469 May 29 22:36 gsromfs1.c
-rw-rw-rw-    1 william  users    22184469 May 29 22:36 gsromfs1_.c
-rwxrwxrwx    1 william  users      108735 May 29 22:36 mkromfs
-rwxrwxrwx    1 william  users      108735 May 29 22:36 mkromfs_0
-rw-rw-rw-    1 william  users        7612 May 29 22:36 iconfig.o
-rw-r--r--    1 william  users        5704 May 29 22:36 gconfig.c
-rw-rw-rw-    1 william  users       16051 May 29 22:36 gconfig.h
-rw-rw-rw-    1 william  users       20988 May 29 22:36 gconfig.o
-rw-rw-rw-    1 william  users       16051 May 29 22:36 gconfxx.h
-rw-rw-rw-    1 william  users        1588 May 29 22:36 gs.o
-rw-r--r--    1 william  users        2567 May 29 22:36 gscdefs.c
-rw-rw-rw-    1 william  users        2172 May 29 22:36 gscdefs.o
-rw-r--r--    1 william  users        2884 May 29 22:36 iconfig.c
-rw-rw-rw-    1 william  users       16443 May 29 22:36 ld.tr
-rw-rw-rw-    1 william  users        1052 May 29 22:36 gp_strdl.o
-rw-rw-rw-    1 william  users        1580 May 29 22:36 gsnorop.o
-rw-rw-rw-    1 william  users          55 May 29 22:36 iscale.dev
-rw-rw-rw-    1 william  users         124 May 29 22:36 libcore.dev
-rw-rw-rw-    1 william  users          21 May 29 22:36 noroplib.dev
-rw-rw-rw-    1 william  users        5304 May 29 22:36 sidscale.o
-rw-rw-rw-    1 william  users          22 May 29 22:36 strdline.dev
-rw-rw-rw-    1 william  users        8088 May 29 22:36 siscale.o
-rw-rw-rw-    1 william  users        2784 May 29 22:36 gdevdsha.o
-rw-rw-rw-    1 william  users       12776 May 29 22:36 gdevm64.o
-rw-rw-rw-    1 william  users         346 May 29 22:36 libd.dev
-rw-rw-rw-    1 william  users        4128 May 29 22:36 siinterp.o
-rw-rw-rw-    1 william  users       14600 May 29 22:36 gdevm56.o
-rw-rw-rw-    1 william  users       13928 May 29 22:36 gdevm48.o
-rw-rw-rw-    1 william  users       11788 May 29 22:36 gdevm32.o
-rw-rw-rw-    1 william  users       13928 May 29 22:36 gdevm40.o
Comment 5 Chris Liddell (chrisl) 2011-05-30 15:12:24 UTC
(In reply to comment #4)
> Thanks again.

No problem, I'm glad we got it addressed quickly.

> By the way, has anyone reported problems with gsromfs1.c?
<SNIP>

This has nothing to do with the subject of this bug report.

Please keep discussion threads on bugs on topic.
Comment 6 William Bader 2011-05-30 15:32:08 UTC
>Please keep discussion threads on bugs on topic.

OK.  I'll reboot the server later this week, and if it still happens, I'll create a new bug report.

William
Comment 7 Ray Johnston 2011-05-30 18:53:31 UTC
On the (off-topic) issue of the compilation of gsromfs1.c I consider excessive
compile times for such a simple file a COMPILER bug, not our issue. I noticed
that on my fast laptop (core i5 3GHz with 6Gb) it compiles with MS Visual tools
(6, 7, 8, 9 or 10) in about 15 seconds. With the Intel compiler on the same
system it took > 1.5 hours (I don't recall the version, but it was current
about 6 months ago). I raised this issue with Intel and never heard back.

I suspect that the C++ compilers (for some reason) are particularly prone to
misbehavior, so using a gcc that is NOT C++ may help. We will take a look at
changes from users to emit (as an option) romfs structures as ASM or OBJ on
problematic systems, but we REALLY aren't that interested in problems on fringe
toolchains, so they will definitely fall back to the submitter if any problems
crop up in the future.

It's not like we are violating common (modern) compiler rules or restrictions.

Anyone considering "improvements" on the toolchain should be committed to long
term involvement. We are going to be changing some aspects of 'mkromfs' and
if we don't get good third party support, we are most likely to just remove
any such "improvements".
Comment 8 William Bader 2011-05-30 19:42:03 UTC
>With the Intel compiler on the same system it took > 1.5 hours

I was curious if it was just me.

>using a gcc that is NOT C++ may help

On all of the systems, I used gcc-4.6.0 built from source, and I build only the C language.  (Since the g++ ABI changes so frequently, even if I built the C++ language, it would be a pain to use because I would have to rebuild most of the C++ development libraries that came with the Linux distribution.)

>We will take a look at changes from users to emit (as an option) romfs structures as ASM or OBJ on problematic systems

For gsromfs1.c, I was wondering about keeping it in C but breaking up each section into a file, which should be portable and would not require asm or obj.

I think that the pcfb module used to have some in-line assembly, so there is a precedent for assembly, but I agree that asm could be hard to maintain.

In any case, gcc did eventually complete and generated working gs.
The slow compile is just a build server in a back room, and I build gs only for new releases, so as long as I know that will eventually finish, it good enough.

>It's not like we are violating common (modern) compiler rules or restrictions.

I think that the ISO standard recommends minimum values for some compiler limits, but the values are small enough that conforming compilers can be hosted on 16 bit systems.  gsromfs1.c ends up to be almost 1/4 million lines, which might be the largest module that I have tried to compile.