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

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.

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.

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

(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.

>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

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".

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