| Summary: | Missing letter(s?) in Acrobat 5 | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Jack Moffitt <jack> |
| Component: | PDF Writer | Assignee: | L. Peter Deutsch <ghost> |
| Status: | NOTIFIED WONTFIX | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | master | ||
| Hardware: | All | ||
| OS: | All | ||
| Customer: | Word Size: | --- | |
|
Description
Jack Moffitt
2001-06-25 05:57:53 UTC
Comment originally by rodw@users.sourceforge.net Logged In: YES user_id=251410 In my experience with Acrobat in a professional printing environment, truetype is ALWAYS an issue. Most problems go away if you tell the printer driver to download truetype fonts as outlines. This converts all TT fonts to Type 1 Postacript fonts and Distiller (and more importantly, the output device gets it right. On most of my RIPS, truetype fonts from Acrobat 4.0 cause a PS error. Might help your problem. Comment originally by rjvbertin@users.sourceforge.net Logged In: YES user_id=93983 Well, I could try to switch back to using outlines, of course... The readme that comes with adobeps (I since discovered that they're at version 4.51!) explains that it is usually better to use Type42 if the RIP can handle it. And indeed, the considerable problems that I mentioned (a font becoming useless even in Windows after 1x printing!) disappeared when I changed to sending as Type42. I have been able to isolate 2 glyphs in the particular font that are the cause, but I don't succeed in "repairing" them (or the hinting). You talk about printing environment. I think this, and generating pdf, are slightly different issues. For a nice pdf, it is probably desirable to include truetype fonts as truetype. gs 7 is capable of that now, luckily - I find the quality (on-screen at least!) has significantly improved because of this. When printing from acrobat, one can then always configure the printerdriver such that optimal printing results... BTW, I did succeed in "repairing" the icircumflex such that I now get correct behaviour. The interesting bit is that I know that this same glyph did not always display correctly under Mac OS 7.x ... Thanks for the suggestion anyway. Comment originally by dancoby@users.sourceforge.net Logged In: YES user_id=12908 What exactly, if anything, would you like us to do? If I read your report correctly, Ghostscript was not involved in the creation of the files involved. Note: We have found that the presence of kerning information in an embedded font causes Acrobat 5.0 to not display text. This problem does not exist in Acrobat 4.0. Comment originally by rjvbertin@users.sourceforge.net Logged In: YES user_id=93983 I dunno :) Yes, ghostscript was involved in the creation! I checked with Distiller to see whether this was a ghostscript-particular problem, or a more general problem. I mentioned it here because I thought that it might be of interest for those working on the pdf writer (there may be workarounds?). The note on kerning is interesting. As I mentioned in my previous post, in my case the problem disappeared when I recreated the offending glyph (composite, apparently with additional hinting). Comment originally by dancoby@users.sourceforge.net Logged In: YES user_id=12908 >Yes, ghostscript was involved in the creation! I checked with Distiller to see whether this was a ghostscript- particular problem, or a more general problem. Perhaps I am missing something. Your report says: 1.> See the attached archive. No archive was attached. I also have not found anthing pertaining to this problem sent to any of our standard bug reporting mail boxes. 2.> The .ps file has been created with StarOffice 5.2 under windows 95, printing to the "Acrobat Distiller 4" printer (to file) via the adobeps 4.4.1 driver. Ghostscript not mentioned in this process. 3.> When viewed in gs7 (with gsview 4.0), everything seems to be OK. Here Ghostscript is used to view the file (not create) and everything works as desired. 4.> Viewed in Acrobat 5, however, an icircumflex is missing from the line "Surus-k n, ens d'Umma" on the 2nd page. (There may be more missing but I didn't verify this). Adobe Acrobat 5.0 5.> The icircumflex is there when I view with gs7.00. Views correctly using Ghostscript. No mention of file being created by Ghostscript. 6.> When I convert the .ps file with Acrobat Distiller 4 (result included too; the c43-distiller4.pdf), viewing seems OK in Acrobat 4, but there are substantial misses around that same position in Acrobat Reader 5. Adobe Acrobat Distiller 4 and Reader 4 and 5.0. Comment originally by dancoby@users.sourceforge.net Logged In: YES user_id=12908 >Yes, ghostscript was involved in the creation! I checked with Distiller to see whether this was a ghostscript- particular problem, or a more general problem. Perhaps I am missing something. Your report says: 1.> See the attached archive. No archive was attached. I also have not found anthing pertaining to this problem sent to any of our standard bug reporting mail boxes. 2.> The .ps file has been created with StarOffice 5.2 under windows 95, printing to the "Acrobat Distiller 4" printer (to file) via the adobeps 4.4.1 driver. Ghostscript not mentioned in this process. 3.> When viewed in gs7 (with gsview 4.0), everything seems to be OK. Here Ghostscript is used to view the file (not create) and everything works as desired. 4.> Viewed in Acrobat 5, however, an icircumflex is missing from the line "Surus-k n, ens d'Umma" on the 2nd page. (There may be more missing but I didn't verify this). Adobe Acrobat 5.0 5.> The icircumflex is there when I view with gs7.00. Views correctly using Ghostscript. No mention of file being created by Ghostscript. 6.> When I convert the .ps file with Acrobat Distiller 4 (result included too; the c43-distiller4.pdf), viewing seems OK in Acrobat 4, but there are substantial misses around that same position in Acrobat Reader 5. Adobe Acrobat Distiller 4 and Reader 4 and 5.0. Comment originally by rjvbertin@users.sourceforge.net Logged In: YES user_id=93983 Ok, sorry, I wasn't clear: I discovered the problem in a pdf file created with gs7. I guess I have a problem talking to people as I do to my computers >8- Re 1:) I am very positive I did attach an archive, however. I do seem to remember having seen some message about the size of the attachment, but it didn't remain visible long enough to register. If the attachment is indeed not there because of a size limit, it would be good if it were indicated, with alternatives! If anyone wants to look into this, I'll send the archive if I still can find it. Comment originally by jackiem@users.sourceforge.net Logged In: YES user_id=206537 Can you submit the postscript file you are testing with? We'll need it if we're going to track down the problem. Comment originally by rjvbertin@users.sourceforge.net Logged In: YES user_id=93983 There should be a zipped postscript file uploaded with this message. Comment originally by rjvbertin@users.sourceforge.net Logged In: YES user_id=93983 &^%$@#$()! Only 256000 bytes allowed, I now saw. Well, then this one should pass. Only the 1st 2 pages. Created from StarOffice 5.2, using adobeps 4.51 with the Distiller 4 ppd. Comment originally by lpd@users.sourceforge.net Logged In: YES user_id=8861 Sorry, I don't understand the exact sequence of operations to reproduce the problem. I converted c43.ps using the current ps2pdf, and the result was displayed correctly with Acrobat Reader 4 for Linux. Does the problem only occur with AR5? Or do I need special options for ps2pdf? Please advise. Comment originally by rjvbertin@users.sourceforge.net Logged In: YES user_id=93983 1) convert using (current) ps2pdf, without any options. 2) view in Acrobat 4: result should be correct (cf. my initial posting; verified) 3) View in Acrobat 5: problem should be there as mentioned. In other words, as far as I can tell, this problem is indeed specific to AR5. (I no longer have AR4 on a Win9x machine, and AFAIK AR5 does not exist for Linux.) Do you need any more specifics? Comment originally by lpd@users.sourceforge.net Logged In: YES user_id=8861 Thanks for the clarification. I (lpd) only run Linux, so I can't investigate any further: I've reassigned the problem to jackiem. Comment originally by lpd@users.sourceforge.net Logged In: YES user_id=8861 This is probably the same problem as #434707. We'll review this one after we have a fix for that one. Comment originally by lpd@users.sourceforge.net Logged In: YES user_id=8861 It appears that this is *not* the same problem as #434707, at least not entirely, now that I've investigated the situation in more depth. When I convert the c43.ps file with ps2pdf, Acrobat Reader (AR) 4 on Linux and AR5 on Windows display it with the i-circumflex of "Surus-kin" missing. When I convert the file with Acrobat Distiller (AD) 5 on Windows, AR5 on Windows displays the file with the *entire rest of the line* missing, starting at the i-circumflex. I looked at the file very carefully. The i-circumflex character is glyph #196 in font MSTT3190f18bf7tS00. This glyph is a composite glyph, made up of glyph #7 (dotless i) and glyph #116 (circumflex). The "flags" for the glyph #116 component have the value 0x102, indicating that the component position is given as X and Y coordinates rather than using point numbers, but that the coordinates each only occupy a single (2's complement) byte rather than the more customary 16 bits. No other glyph in this font uses this "flags" setting, and I think AR simply handles it wrong. I have reported this bug to Adobe. Making ps2pdf work around this bug is somewhat awkward: it will have to modify the actual glyph description, inserting 2 bytes and adjusting some lengths. Unfortunately, I see no alternative to doing this. I will look into this next. Comment originally by lpd@users.sourceforge.net Logged In: YES user_id=8861 I've modified pdfwrite to always produce 16-bit X and Y offsets for composite glyphs. The resulting file now displays correctly with AR4 on Linux, but AR5 on Windows still omits the i-circumflex. I'll continue to explore this problem. Comment originally by lpd@users.sourceforge.net Logged In: YES user_id=8861 I was wrong; AR4 on Linux displays the converted file properly even before the modification. So the modification did not improve the situation at all. I will wait for Adobe to get back to me about the Acrobat bugs. Comment originally by rjvbertin@users.sourceforge.net Logged In: YES user_id=93983 I see I submitted an interesting problem :) I remember that I have at other problems with this same glyph (icircumflex), even with displaying it under some versions of the MacOS. If I remember correctly, I "solved" these by recreating the glyph (I use FontLab 3x). I'll see if I can retrieve the document that was used to create c43.ps, to see what happens now. BTW: there is an AR update (5.05) that contains a substantial number of bug fixes! RenE Comment originally by lpd@users.sourceforge.net Logged In: YES user_id=8861 Acrobat Reader 5.0.5 for Windows also replaces the icircumflex with a narrow blank. Comment originally by rjvbertin@users.sourceforge.net Logged In: YES user_id=93983 Update. I just updated to ghostscript 7.04 . Essentially, nothing has changed concerning the pdf generation: the resulting pdf is shown correctly in acroread 4.05/linux, but not in reader 5.05/WIndows (shows narrow space indeed). HOWEVER, when I try to render c43.ps via gv, gs core dumps (both the dynamically and the statically linked version). This doesn't happen with v. 7.00, nor when I run gs directly (resulting in an enormous window). When I try to view the file under Windows via gsview 4.2, well... Basically, I get a huge window, and a severe out-of-memory-and-disk situation ("fit-window-to-page" option on). Without that option, gs/gsview stubbornly keeps giving me the 1:1 (or thereabouts) view instead of the smaller. I know this is not the thread for these issues, but is this a known issue? Comment originally by lpd@users.sourceforge.net Logged In: YES user_id=8861 It seems clear that there is a problem with this font that has nothing to do with Ghostscript, since Acrobat Reader won't display the output of Acrobat Distiller correctly either. Therefore, we are closing the report. Please report the other problems to their appropriate place. |