| Summary: | PDF interpreter needs languagelevel 3, not 2 | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | SaGS <sags5495> |
| Component: | PDF Interpreter | Assignee: | Alex Cherepanov <alex> |
| Status: | NOTIFIED FIXED | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | All | ||
| Customer: | Word Size: | --- | |
| Attachments: | Recommended minimum patch. | ||
Created attachment 1460 [details] Recommended minimum patch. The patch modifies only pdfwrite.ps to save/ restore the languagelevel. The question at which languagelevel is the PDF interpreter supposed to run, and what should happen if a lower languagelevel is in effect, remains. The answer depends in part on the outcome of bug #688150 "ReusableStreamDecode available but failing at languagelevel 2" (more precisely, if LL3 filters remain available at LL2). --- Changing the other 5 files is more problematic. If they do a save/ restore of the languagelevel, subsequent INITFILES are parsed at LL1. Some of these incorrectly omit setting LL2 even if they need it. I found such problems with the following: gs_cff.ps: In line #70 "30 dict begin" the dict size is insufficient (needs 53 or more); at LL1, fails with "Error: /dictfull in def". gs_dpnxt.ps: Calls "(current|set)global" (without a leading dot) in 3 places. I recommend using ".(current|set)global" (with a dot). gs_epsf.ps, gs_icc.ps, gs_pdfwr.ps: Use "<< .. >>", failing with a syntaxerror at LL1. In addition to these problems, when loading those files at LL1 some operators are not available and won't be bound into the procedures. Passing to Alex who owns the PDF interpreter. The minimal patch, dictionary size change, and dotted (current|set)global operators are adopted and committed as a rev. 9246. I didn't replace '<< >>' operators because this would reduce readability. The start-up files are not expected to be loaded in level 1 mode. |
Although the PDF interpreter & utilities use languagelevel 3 features, some files that implement them force languagelevel 2. These files are: pdf_base.ps, pdf_draw.ps, pdf_font.ps, pdf_main.ps, pdf_sec.ps, and pdfwrite.ps. It's true that LL2 is enough to parse these files, but executing the procs defined in them requires LL3. If loaded as INITFILES, this has no effect, as the final languagelevel is set in "gs_init.ps" after loading them. However "pdfwrite.ps" is loaded explicitely by "pdfopt.ps" and "pdfinflt.ps"; in this case, languagelevel remains 2 and, at least for PDF1.5+ files with xref-streams, bug #688150 "ReusableStreamDecode available but failing at languagelevel 2" kicks in. Command line to reproduce the error (Windows): pdfopt.bat PDFReference16.pdf out.pdf ("PDFReference16.pdf" being the PDF 1.6 Reference Manual).