When I use the Degree-Symbol (°), it will be placed to narrow to the previous character in Arial font. Thus, if I have 5°C, it looks quite odd. I am not sure where this happens, but it only happens in Arial. What to do to reproduce it: Using PDFCreator (www.pdfforge.org), print a Word document with "5°C" in different fonts, one of them being Arial. (it goes through a PS Printer to Ghostscript) Save it as PDF. You will see, that the degree symbol is misplaced
Please create a PDF file and attach it here, we cannot guarantee to follow the exact same sequence of steps using the same software you have used and so might be unable to reproduce the problem.
Created attachment 5785 [details] test pdf file
I have attached a file. This is done with GS 8.64
The PDF file looks the same rendered with Ghostscript and viewed with Acrobat 9. The spacing is given directly in the PDF file using a TJ operation and appears to be deliberate. Perhaps I'm mis-understanding your issue, are you complaining that the online service using Ghostscript is producing an incorrect result ? If so I would suggest you take this up with the online service. We will need details of command line configuration, as well as a PostScript file exhibiting the problem, and evidence that this problem persists on the current version of Ghostscript (8.70). I haven't tried using this service, but I presume you can't supply all this information. In any event, it doesn't look like this is a PostScript interpreter problem at the moment.
This problem is likely to be a duplicate of the bug 687297 and the bug 687886. I cannot explain in printable language why it has not been fixed since 2005. Please print your word file to a PostScript file and attach the PostScript file to the bug report to verify this.
Created attachment 5799 [details] PostScript file
Created attachment 5800 [details] PDF File Here comes a sample PostScript file which shows this behaviour
I am using these Command Line parameters when converting: -q -dNOPAUSE -dBATCH -sFONTPATH=C:\Windows\Fonts -sDEVICE=pdfwrite -dPDFSETTINGS=/default -dCompatibilityLevel=1.4 -r600x600 -dProcessColorModel=/DeviceCMYK -dAutoRotatePages=/PageByPage -dCompressPages=true -dEmbedAllFonts=true -dSubsetFonts=true -dMaxSubsetPct=100 -dConvertCMYKImagesToRGB=false -sOutputFile=C:\Users\Philip\Desktop\Dokument1.pdf -dEncodeColorImages=true -dAutoFilterColorImages=true -dEncodeGrayImages=true -dAutoFilterGrayImages=true -dEncodeMonoImages=true -dMonoImageFilter=/CCITTFaxEncode -dDownsampleMonoImages=false -dPreserveOverprintSettings=true -dUCRandBGInfo=/Preserve -dUseFlateCompression=true -dParseDSCCommentsForDocInfo=true -dParseDSCComments=true -dOPM=0 -dOffOptimizations=0 -dLockDistillerParams=false -dGrayImageDepth=-1 -dASCII85EncodePages=false -dDefaultRenderingIntent=/Default -dTransferFunctionInfo=/Preserve -dPreserveHalftoneInfo=false -dDetectBlends=true -f
This needs more analysis. URW claim the metrics are correct, ken decoded NimubusSanL-Regu our helvetica and the metrics seems reasonable lsb=151 and advance=606 and the glyph displays reasonably in fontforge, something else other than the glyph metrics must be causing the spacing problem.
The PDF attachment file submitted by the bug reporter has all fonts embedded as subsets with the exception of supposedly used "Arial" and "Times New Roman" (http://bugs.ghostscript.com/attachment.cgi?id=5800). AcroReader reports in document properties -> fonts that the original fontname referenced is "ArialMT" (not "Arial"), and that it uses "Helvetica" to display it. The glyph name in question seems to be "degree". That glyph's implementation differs between Adobe's Helvetica and Ghostscript's look-alike NimbusSanL-Regu in that NimbusSanL-Regu places that little ring-shape considerably more to the right than Adobe's Helvetica does. I created two PDF files from a WinWord document, using two different font handling methods. First stage was "printing to file" with a Adobe PostScript driver, applying the two different font handling methods: 1. Set "TrueType font handling" to 'Replace with device fonts'. 2. Set "TrueType font handling" to 'Download to printer as softfont', including the "PostScript TrueType Download Option" as 'TrueType' (NOT 'Outline', 'Bitmap' or 'Auto'). Second stage was converting the resulting PostScript files to PDF, both with the same commandline. Here are the relevant params to that commandline: gswin32c.exe ^ -dPDFA ^ -dPDFACompatibilityPolicy=1 ^ -sOutputFile="%prnfile%.pdf" ^ -sDEVICE=pdfwrite ^ -dPDFSETTINGS=/prepress ^ -dCompressFonts=false ^ -dSubsetFonts=false ^ -dCompatibilityLevel=1.4 ^ -dHaveTrueTypes=true ^ -d.IgnoreNumCopies=false -c ".setpdfwrite <</NeverEmbed [ ]>> setdistillerparams 10000000 setvmthreshold" ^ -f "%prnfile%" 1>> "%logfile%" 2> "%logfile%.gserr" The first type of PDF creation resulted in WinWord's ArialMT (TrueType) being replaced by the Ghostscript's "Helvetica" (really NimbusSansL-Regu) giving the weird-looking "degree" glyph. The second type of PDF creation resulted in WinWord's ArialMT (TrueType) being embedded into the PDF as-is, and giving a WYSIWYG-lookalike for the PDF compared to the WinWord screen window. (Note, that both files have all fonts embedded. Note, that Verdana and Tahoma are embedded as TT in both methods.)
Created attachment 6416 [details] Arial TrueType font embedded as TrueType in PDF
Created attachment 6417 [details] Arial TrueType font substituted as so-called "Helvetica" (really NimbusSansL-Regu) in PDF
Comment on attachment 6417 [details] Arial TrueType font substituted as so-called "Helvetica" (really NimbusSansL-Regu) in PDF This one displays the 'weird' looking "degree" glyph.
Comment on attachment 6416 [details] Arial TrueType font embedded as TrueType in PDF This one displays the "degree" glyph as expected.
it looks like the FreeType integration in GS 9.00 has finally fixed this :) Thanks to everyone involved here
I don't know what is different now, but it does not work again. Is there anything special needed to use FreeType? The Font is embedded as ArialMT again.
I don't understand your comment: are you saying that the misplaced degree symbol was fixed and is now broken again, or that the embedded font naming has changed? When I looked into the PS job, it is positioning each glyph individually with the xshow PS operator. Thus the job is not using the metrics from the font to get the horizontal advance. Replacing the xshow with a straight "show" operation, reveals the glyphs to be correctly spaced when using the font's own metrics for the horizontal advance. I concluded the job, rather than the font, was thus at fault. When a job does that kind of manipulation, then only way to be sure of consistent results is to ensure the font is embedded in the job. It is possible that our Arial substitute has slightly different metrics from the Arial used to create the job (it is a reasonable substitute, not a clone), or possibly (more likely, given the symptoms?) that the Arial from which the producing application extracted the metrics in order to specify the horizontal advance had an error in its metrics (and could easily have been an earlier version of the GS font set). I'll leave this open for now, in case I've misunderstood something.
thank you for the quick reply. When I wrote comment 15, it seemed to work just fine. Now it does not work again, so I am trying to find out what is different to the last time. The PS file is generated from the Windows Printer Driver, so I am not really able to do something there. The fonts are marked to be embedded in the PDF and are available, as GS is run on the machine where the PS file was generated. As I do not understand too much about the PS internals: You say that the way the job sets the characters is not quite right and using show would correct that?
Two of the fonts aren't embedded in either the PS source, nor the PDF ( http://bugs.ghostscript.com/attachment.cgi?id=5800 ): Times-Roman and Helvetica (used for Arial). As both Times-Roman and Helvetica are Postscript/PDF "base fonts" they are generally not embedded. The method of glyph positioning is not "wrong", but as I said, can be a bit risky unless you can guarantee the same font versions from the same foundry are available throughout the workflow. Okay, here's a suggestion: If you go to "Control Panel"-> Printers and right-click the PDFCreator printer device, and select "Properties" from the context menu. In the resulting dialogue, select the "Device Settings" tab. In that tab, is a "tree" of settings, and there should be a collapsed list of the "Font Substitution Table". Click the "+" to expand the font "Font Substitution Table", and scroll down to find the entry for "Arial". It defaults to substituting Arial with Helvetica. Clicking where it lists Helvetica as the substitute for Arial will give you a drop down menu of other options - from it, select "Don't Substitute". While you're there, there is also a similar entry for Times-Roman to substitute with Times, I'd also change that to "Don't Substitute" for the most consistent results. Click "Apply", and retest. With those settings I get a nice PDF out with the correct spacing. Hope that's of some help!
Thank you that was the hint! Though I do not have the option to edit the font substitution table directly, I was able to set the handling of TrueType fonts from "Replace with device font" to "Load as Softfont" and that works. again, thank you very much :)
Strange, I used the PDFCreator 1.2.0 install I have to experiment for that solution, so i assumed yours would be the same. Oh well, it should now mean that the font consistent across the entire workflow, which is really what we want. Are you, then, happy for me to close this bug?
Yes, I was using PDFCreator 1.2.0 as well. Thank you very much, this bug can be closed
Great, thanks!