Cid font dictionary error

CID кодировка

Vadim_PDF

Vadim_PDF

Ответ: CID кодировка

Да забыл, происходит это не совсеми шрифтами и не всегда, возможно исходные шрифты не совсем верны, но проблема не в этом. Ведь если он корректно вставился в кодировке CID, то это уже по большому счёту отдельный специфический шрифт, и это проблемы Adobe (она закодировала, она пусть и раскодирует!)

Shlyapa

Участник

Ответ: CID кодировка

О CID и Custom тут уже говорили. Поиском поищи.

Shit happens. (Forrest Gump)

Человек без веры в бога — всё равно, что рыба без велосипеда.​

Vadim_PDF

Ответ: CID кодировка

По поводу избавления от CID шрифтов. Не получаеться по методу Shlyapa затянуть в InDesign и распечатать на PS принтер с уровнем ps Level 2. Что-то не так. Есть файл (приаттачен) Настройки принтера и Индизайна видите. В результате при печати в ps с уровнем 2 (который вроде как не понимает (не поддерживает cid шрифты)) на выходе из дистилера получаем то же самое. Попробуйте, может у вас получиться?
Или я что-то не так сделал?

Вложения

Shlyapa

Участник

Ответ: CID кодировка

Плохо помню, но кажется «мой метод» работал в InD 2.

Из InD (и AI) CS и Acrobat 7 из твоего PDF-а у меня тоже выходит только CID-кодировка.
При том, что текст, набранный прямо в InD рядом с этим PDF-ом, и, соответсвенно, выводящийся с ним одновременно, в конечном итоге получается Custom.
Использую адобовский OTF и т.н. правильный Type1 — резульатт один и тот же.
А ты, Vadim_PDF, какие шрифты используешь?

Вложения

Shit happens. (Forrest Gump)

Человек без веры в бога — всё равно, что рыба без велосипеда.​

Vadim_PDF

Ответ: CID кодировка

Какой шрифт («правильный» — «не правильный») использовался к сожалению не знаю, так как имею готовый pdf заказчика. Проблема в том, что иногда получаеться, иногда нет. В чём причина и какая зависимость не знаю, пока не определил.
Где то слышал, что последние версии программ Adobe даже в ps 2 Level вкладывают какую-то информацию для 3 уровня, и если выводное устройство (в данном случае дистилер) поддерживает Level 3, то и «рипует» файл по этой технологии. А если нет — то нет. Может от туда и ноги растут. Берёт Дистилер файл, открыл, смотрит ps-2, но есть что то вроде кода ps-3, вот и берёт то что считает более правильным! Иначе как объяснишь, что через файл не поддерживающий cid, эта cid кодировка просачиваеться.
Хотя данная информация у меня на уровне слухов и догадок. Может есть экспеты которые помогут? А то замахался отдавать на вывод «курвированые» файлы гнать.

Источник

[tx] Valid operators in Font DICT of CID-keyed CFF #137

According to cffwrite_dict.c or absfont.h, it seems only four operators are valid in Font DICT:

Are they explicitly stated in some technotes? I couldn’t find it.

The text was updated successfully, but these errors were encountered:

While not explicitly stated, I think that the closest Adobe Tech Note is #5014, which implicitly states this via its examples. (There is also FontType , which is a fifth operator, though I suspect that it is not necessary for CFF (because its value is implicit in CFF), but for CIDFont resources.)

Thank you for clarifying!

BTW, fontTools’ cffLib can complie any Top DICT operators that appear in Font DICT (see cffLib.py#L1434). How should we treat such invalid entries? Just ignore or undefined behavior? tx -t1 seems to treat the last value of each operator as the actual Top DICT’s value.

This is a bug in ‘tx’. I will change ‘tx’ to ignore any such operators: it will just pop the operator and its operands from the stack, and emit a warning.

@mashabow if you think cffLib needs fixing, could you also file an issue on the fontTools repo? Thanks.

The closest I can find to a definition for an FDArray FontDict is from Tech Note 5014 page 31. I include this below. This section excludes only a couple of keys and says otherwise that an FDArray FontDict is a PostScript FontDict, which implies that all other keys are permissible. However, I think this is an oversight in the spec, and I agree with Ken Lunde’s list for keys that are actually used. Furthermore, most of the other TopDict keys are used in text layout and. in the context of OpenType, are ignored as they overridden by data in other OpenType tables.

from Page 31, Tech Note 5014. 11 June 1993:

Each font dictionary in a CIDFont of CIDFontType 0 is a font dictionary as
described in the PostScript Language Reference Manual, Second Edition,
with certain exceptions. These font dictionaries may be Type 1 or Type 3 font
dictionaries, but must not include the following entries:
Type 1 Exceptions
Encoding Array Should not be present in an FDArray font dictionary
because the CMap file controls encoding.
Charstring Dictionary Should not be present in an FDArray font dictionary
because charstring information appears in a data block near the end
of the CIDFont file.
32 Adobe CMap and CIDFont Files Specification (11 June 93)
Subrs Array Should not be present in an FDArray font dictionary
because subroutine information appears in a data block near the end
of a CIDFont file along with charstrings and offset and index information.
Type 3 Exceptions
Encoding Array Should not be present in an FDArray font dictionary
because the CMap file controls encoding.

Источник

Type 1 Tables¶

Synopsis¶

This section contains the definition of Type 1-specific tables, including structures related to other PostScript font formats.

PS_FontInfoRec¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

A structure used to model a Type 1 or Type 2 FontInfo dictionary. Note that for Multiple Master fonts, each instance has its own FontInfo dictionary.

PS_FontInfo¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

A handle to a PS_FontInfoRec structure.

PS_PrivateRec¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

A structure used to model a Type 1 or Type 2 private dictionary. Note that for Multiple Master fonts, each instance has its own Private dictionary.

PS_Private¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

A handle to a PS_PrivateRec structure.

CID_FaceDictRec¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

A structure used to represent data in a CID top-level dictionary. In most cases, they are part of the font’s ‘/FDArray’ array. Within a CID font file, such (internal) subfont dictionaries are enclosed by ‘%ADOBeginFontDict’ and ‘%ADOEndFontDict’ comments.

Note that CID_FaceDictRec misses a field for the ‘/FontName’ keyword, specifying the subfont’s name (the top-level font name is given by the ‘/CIDFontName’ keyword). This is an oversight, but it doesn’t limit the ‘cid’ font module’s functionality because FreeType neither needs this entry nor gives access to CID subfonts.

CID_FaceDict¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

A handle to a CID_FaceDictRec structure.

CID_FaceInfoRec¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

A structure used to represent CID Face information.

CID_FaceInfo¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

A handle to a CID_FaceInfoRec structure.

FT_Has_PS_Glyph_Names¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

Return true if a given face provides reliable PostScript glyph names. This is similar to using the FT_HAS_GLYPH_NAMES macro, except that certain fonts (mostly TrueType) contain incorrect glyph name tables.

When this function returns true, the caller is sure that the glyph names returned by FT_Get_Glyph_Name are reliable.

input

return

Boolean. True if glyph names are reliable.

FT_Get_PS_Font_Info¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

Retrieve the PS_FontInfoRec structure corresponding to a given PostScript font.

input

PostScript face handle.

output

A pointer to a PS_FontInfoRec object.

return

FreeType error code. 0 means success.

String pointers within the PS_FontInfoRec structure are owned by the face and don’t need to be freed by the caller. Missing entries in the font’s FontInfo dictionary are represented by NULL pointers.

The following font formats support this feature: ‘Type 1’, ‘Type 42’, ‘CFF’, ‘CID Type 1’. For other font formats this function returns the FT_Err_Invalid_Argument error code.

example

FT_Get_PS_Font_Private¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

Retrieve the PS_PrivateRec structure corresponding to a given PostScript font.

input

PostScript face handle.

output

A pointer to a PS_PrivateRec object.

return

FreeType error code. 0 means success.

The string pointers within the PS_PrivateRec structure are owned by the face and don’t need to be freed by the caller.

Only the ‘Type 1’ font format supports this feature. For other font formats this function returns the FT_Err_Invalid_Argument error code.

example

FT_Get_PS_Font_Value¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

Retrieve the value for the supplied key from a PostScript font.

input

PostScript face handle.

An enumeration value representing the dictionary key to retrieve.

For array values, this specifies the index to be returned.

A pointer to memory into which to write the value.

The size, in bytes, of the memory supplied for the value.

output

The value matching the above key, if it exists.

return

The amount of memory (in bytes) required to hold the requested value (if it exists, -1 otherwise).

The values returned are not pointers into the internal structures of the face, but are ‘fresh’ copies, so that the memory containing them belongs to the calling application. This also enforces the ‘read-only’ nature of these values, i.e., this function cannot be used to manipulate the face.

value is a void pointer because the values returned can be of various types.

If either value is NULL or value_len is too small, just the required memory size for the requested entry is returned.

The idx parameter is used, not only to retrieve elements of, for example, the FontMatrix or FontBBox, but also to retrieve name keys from the CharStrings dictionary, and the charstrings themselves. It is ignored for atomic values.

PS_DICT_BLUE_SCALE returns a value that is scaled up by 1000. To get the value as in the font stream, you need to divide by 65536000.0 (to remove the FT_Fixed scale, and the x1000 scale).

IMPORTANT: Only key/value pairs read by the FreeType interpreter can be retrieved. So, for example, PostScript procedures such as NP, ND, and RD are not available. Arbitrary keys are, obviously, not be available either.

If the font’s format is not PostScript-based, this function returns the FT_Err_Invalid_Argument error code.

since

T1_Blend_Flags¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

A set of flags used to indicate which fields are present in a given blend dictionary (font info or private). Used to support Multiple Masters fonts.

values

T1_EncodingType¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

An enumeration describing the ‘Encoding’ entry in a Type 1 dictionary.

values

since

PS_Dict_Keys¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

An enumeration used in calls to FT_Get_PS_Font_Value to identify the Type 1 dictionary entry to retrieve.

values

since

T1_FontInfo¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

This type is equivalent to PS_FontInfoRec . It is deprecated but kept to maintain source compatibility between various versions of FreeType.

T1_Private¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

This type is equivalent to PS_PrivateRec . It is deprecated but kept to maintain source compatibility between various versions of FreeType.

CID_FontDict¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

This type is equivalent to CID_FaceDictRec . It is deprecated but kept to maintain source compatibility between various versions of FreeType.

CID_Info¶

Defined in FT_TYPE1_TABLES_H (freetype/t1tables.h).

This type is equivalent to CID_FaceInfoRec . It is deprecated but kept to maintain source compatibility between various versions of FreeType.

Источник

The closest I can find to a definition for an FDArray FontDict is from Tech Note 5014 page 31. I include this below. This section excludes only a couple of keys and says otherwise that an FDArray FontDict is a PostScript FontDict, which implies that all other keys are permissible. However, I think this is an oversight in the spec, and I agree with Ken Lunde’s list for keys that are actually used. Furthermore, most of the other TopDict keys are used in text layout and. in the context of OpenType, are ignored as they overridden by data in other OpenType tables.

from Page 31, Tech Note 5014. 11 June 1993:

Each font dictionary in a CIDFont of CIDFontType 0 is a font dictionary as
described in the PostScript Language Reference Manual, Second Edition,
with certain exceptions. These font dictionaries may be Type 1 or Type 3 font
dictionaries, but must not include the following entries:
Type 1 Exceptions
Encoding Array Should not be present in an FDArray font dictionary
because the CMap file controls encoding.
Charstring Dictionary Should not be present in an FDArray font dictionary
because charstring information appears in a data block near the end
of the CIDFont file.
32 Adobe CMap and CIDFont Files Specification (11 June 93)
Subrs Array Should not be present in an FDArray font dictionary
because subroutine information appears in a data block near the end
of a CIDFont file along with charstrings and offset and index information.
Type 3 Exceptions
Encoding Array Should not be present in an FDArray font dictionary
because the CMap file controls encoding.

Как было определено в ходе комментариев к вопросу, названия шрифтов анонимизированы во всех метаданных PDF для шрифта, но сама встроенная программа шрифта содержит фактическое название шрифта.

(Таким образом, PDF, строго говоря, нарушен, хотя вряд ли какая-либо программа будет жаловаться на это).

Поэтому, если мы хотим получить эти имена, мы должны заглянуть в эти программы шрифтов.

Вот пример концепции, основанной на архитектуре, использованной в этом ответе, на которую вы ссылались, т.е. с использованием RenderFilter:

Класс MemoryPackage взят из этого ответа, который был моей первой находкой при поиске того, как считать информацию из шрифта в памяти с помощью .Net.

Применяется к вашему PDF-файлу следующим образом:

результат

Остерегайтесь: Это всего лишь доказательство концепции.

С одной стороны, вам, конечно же, потребуется реализовать часть, закомментированную как аналогичный код для других подтипов шрифтов выше; и даже часть TYPE0 не готова к использованию в производстве, поскольку она учитывает только FONTFILE2 и не обрабатывает значения null изящно.

С другой стороны, вы захотите кэшировать имена для уже проверенных шрифтов.

In brief, I’m dealing with a problematic PDF, which:

• Cannot be fully rendered in a document viewer like evince, because of missing font information;
• However — ghostscript can fully render the same PDF.

Thus — regardless of what ghostscript uses to fill in the blanks (maybe fallback glyphs, or a different method to accessing fonts) — I’d like to be able to use ghostscript to produce («distill») an output PDF, where pretty much nothing will be changed, except font information added, so evince can render the same document in the same manner as ghostscript can.

My question is thus — is this possible to do at all; and if so, what would be command line be to achieve something like that?

Many thanks in advance for any answers,
Cheers!

Details:

I’m actually on an older Ubuntu 10.04, and I might be experiencing — not a bug — but an installation problem with evince (lack of poppler-data package), as noted in Bug #386008 “Some fonts fail to display due to “Unknown font tag…” : Bugs : “poppler” package : Ubuntu.

However, that is exactly what I’d like to handle, so I’ll use the fontspec.pdf attached to that post («PDF triggering the bug.», // v.) to demonstrate the problem.

evince

First, I open this pdf’s page 3 in evince; and evince complains:

$ evince --page-label=3 fontspec.pdf

Error: Missing language pack for 'Adobe-Japan1' mapping
Error: Unknown font tag 'F5.1'
Error (7597): No font in show
Error: Unknown font tag 'F5.1'
Error (7630): No font in show
Error: Unknown font tag 'F5.1'
Error (7660): No font in show
Error: Unknown font tag 'F5.1'
...

The rendering looks like this:

… and it is obvious that some font shapes are missing.

Adobe acroread

Just a note on how Adobe’s Acrobat Reader for Linux behaves; the following command line:

$ ./Adobe/Reader9/bin/acroread /a "page=3" fontspec.pdf

… generates no output to terminal whatsoever (for more on /a switch, see Man page acroread) — and the program has absolutely no problem displaying the fonts.

_{Also, while I’d like to avoid the roundtrip to postscript — however, note that acroread itself can be used to convert a PDF to postscript:}

$ ./Adobe/Reader9/bin/acroread -v
9.5.1

$ ./Adobe/Reader9/bin/acroread -toPostScript  
-rotateAndCenter -choosePaperByPDFPageSize 
-start 3 -end 3 
-level3 -transQuality 5 
-optimizeForSpeed -saveVM 
fontspec.pdf ./ 

Again, the above command line will generate no output to terminal; -optimizeForSpeed -saveVM are there because apparently they deal with fonts; the last argument ./ is the output directory (output file is automatically called fontspec.ps).

Now, evince can display the previously missing fonts in the fontspec.ps output — but again complains:

$ evince fontspec.ps 
GPL Ghostscript 9.02: Error: Font Renderer Plugin ( FreeType ) return code = -1
GPL Ghostscript 9.02: Error: Font Renderer Plugin ( FreeType ) return code = -1
...

… and furthermore, all text seems to be flattened to curves in the postscript — so now one cannot select the text in the .ps file in evince anymore (note that the .ps file cannot be opened in acroread). However, one can convert this .ps back into .pdf again:

$ pstopdf fontspec.ps   # note, `pstopdf` has no output filename option;
                        # it will automatically choose 'fontspec.pdf',
                        # and overwrite previous 'fontspec.pdf' in 
                        # the same directory 

… and now the text in the output of pstopdf is selectable in evince, all fonts are there, and evince doesn’t complain anymore. However, as I noted, I’d like to avoid roundtrip to postscript files altogether.

display (from imagemagick)

We can also observe the page in the same document with imagemagicks display (note that image panning from the commandline using ‘display’ is apparently still not available, so I’ve used -crop below to adjust the viewport):

$ display -density 150 -crop 740x450+280+200 fontspec.pdf[2]
   **** Warning: considering '0000000000 00000 n' as a free entry.
...
   **** This file had errors that were repaired or ignored.
   **** The file was produced by: 
   **** >>>> Mac OS X 10.5.4 Quartz PDFContext <<<<
   **** Please notify the author of the software that produced this
   **** file that it does not conform to Adobe's published PDF
   **** specification.

… which generates some ghostscripish errors — and results with something like this:

… where it’s obvious that the missing fonts that evince couldn’t render, are now shown here, with imagemagicks display, properly.

ghostscript

Finally, we can use ghostscript as x11 viewer itself — to observe the same page, same document:

$ gs -sDevice=x11 -g740x450 -r150x150 -dFirstPage=3 
-c '<</PageOffset [-120 520]>> setpagedevice' 
-f fontspec.pdf

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.
   **** Warning: considering '0000000000 00000 n' as a free entry.
   **** Warning: considering '0000000000 00000 n' as a free entry.
   **** Warning: considering '0000000000 00000 n' as a free entry.
   **** Warning: considering '0000000000 00000 n' as a free entry.
   **** Warning: considering '0000000000 00000 n' as a free entry.
   **** Warning: considering '0000000000 00000 n' as a free entry.
   **** Warning: considering '0000000000 00000 n' as a free entry.
Processing pages 3 through 74.
Page 3
>>showpage, press <return> to continue<<
^C

… and results with this output:

In conclusion: ghostscript (and _apparently by extension, imagemagick) can seemingly find the missing font (or at least some replacement for it), and render a page with that — even if evince fails at that for the same document.

I would, therefore, simply like to export a PDF version from ghostscript, that would have only the missing fonts embedded, and no other processing; so I try this:

$ gs -dBATCH -dNOPAUSE -dSAFER  
-dEmbedAllFonts -dSubsetFonts=true -dMaxSubsetPct=99 
-dAutoFilterMonoImages=false 
-dAutoFilterGrayImages=false 
-dAutoFilterColorImages=false 
-dDownsampleColorImages=false 
-dDownsampleGrayImages=false 
-dDownsampleMonoImages=false 
-sDEVICE=pdfwrite 
-dFirstPage=3 -dLastPage=3 
-sOutputFile=mypg3out.pdf -f fontspec.pdf

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.
   **** Warning: considering '0000000000 00000 n' as a free entry.
   **** Warning: considering '0000000000 00000 n' as a free entry.
   **** Warning: considering '0000000000 00000 n' as a free entry.
   **** Warning: considering '0000000000 00000 n' as a free entry.
   **** Warning: considering '0000000000 00000 n' as a free entry.
   **** Warning: considering '0000000000 00000 n' as a free entry.
   **** Warning: considering '0000000000 00000 n' as a free entry.
Processing pages 3 through 3.
Page 3

   **** This file had errors that were repaired or ignored.
   **** The file was produced by:
   **** >>>> Mac OS X 10.5.4 Quartz PDFContext <<<<
   **** Please notify the author of the software that produced this
   **** file that it does not conform to Adobe's published PDF
   **** specification.

… but it doesn’t work — the output file mypg3out.pdf suffers from the exact same problems in evince as noted previously.

_{Note: While I’d like to avoid the postscript roundtrip, a good example of gs command line with from pdf to ps with font embedding is here: (#277826) pdf — How to make GhostScript PS2PDF stop subsetting fonts; but the same command line switches for .pdf to .pdf to not seem to have any effect on the problem described above.}

gs -SDEVICE=tiffg4 -r600x600 -sPAPERSIZE=letter -sOutputFile=_LOTE_51168_01.tiff -dNOPAUSE -dBATCH *.pdf

Can't find CID font "MS-Gothic".
Substituting CID font /Adobe-Japan1 for /MS-Gothic, see doc/Use.htm#CIDFontSubstitution.
The substitute CID font "Adobe-Japan1" is not provided either. Will exit with error.
Error: /undefined in findresource
Operand stack:
--dict:8/17(L)--   F1   10.5   --dict:5/5(L)--   --dict:5/5(L)--   MS-Gothic       --dict:11/12(ro)(G)--   --nostringval--   CIDFontObject   --dict:9/9(L)--   --dict:9/9(L)--   Adobe-Japan1
Execution stack:
%interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1862   1   3   %oparray_pop   1861   1   3   %oparray_pop   1845   1   3   %oparray_pop   --nostringval--   --nostringval--   2   1   1   --nostringval--   %for_pos_int_continue   --nostringval--   --nostringval--   --nostringval--   --nostringval--   %array_continue   --nostringval--   false   1   %stopped_push   --nostringval--   %loop_continue   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   %array_continue   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   %loop_continue
Dictionary stack:
--dict:1154/1684(ro)(G)--   --dict:1/20(G)--   --dict:75/200(L)--   --dict:75/200(L)--   --dict:106/127(ro)(G)--   --dict:286/300(ro)(G)--   --dict:22/25(L)--   --dict:4/6(L)--   --dict:26/40(L)--
Current allocation mode is local
Last OS error: 2
GPL Ghostscript 8.70: Unrecoverable error, exit code 1

2 ответа

Лучший ответ