Description of problem: when print as post script, the upper portion of any character or lines are truncating (cutting). Version-Release number of selected component (if applicable): gedit-2.15.1-2 evince-0.5.2-1 How reproducible: Always Steps to Reproduce: 1. Start gedit in hi_IN locale 2. Enable SCIM with pressing CTRL + SPACE keys. 3. Copy and paste any hindi paragraph. (i.e. website : bbc.co.uk/hindi) 4. Print as post script. 5. Open the post script file. 6. Observe the result. Actual results: The upper (top) portion of the characters are not showing - cutting from the up. Expected results: All the characters in all the lines should show fully without cutting any portion. Additional info: In oowriter the same problem is present. Only difference is, in oowriter, the bold texts are only showing complete character, others not.
It looks good to me with gedit-2.15.8-1.fc6 evince-0.5.5-2.fc6 If you still see this problem with them, it may be helpful if you can provide screenshots and PS file that the problem appears.
Created attachment 135279 [details] screenshot
Created attachment 135280 [details] Postscript File
Not working for me with Following versions: -------------- gedit-2.15.9-1.fc6 evince-0.5.5-2.fc6 -------------- and this is not limited to hind only. Punjabi (pa), Tamil is tested, those are also effected.
Is this still a problem? Could you attach a screenshot showing how it's supposed to look? How does it look if you print it? My guess is that it's a problem with gedit in the way that it generates the postscript. If you print the web-page you mention does the same problem show up?
Created attachment 137081 [details] PNG file output from ghostscript I'm still not sure what the problem is exactly, but I've used ghostscript to convert the postscript file in attachment 135280 [details] to a PNG file, which I'm attaching here. The command used was: gs -dNOPAUSE -sDEVICE=pngalpha -sOutputFile=hi_IN-.png -r200 -- hi_IN-.ps As can be seen, the PNG file is identical to the evince screenshot, so the problem is either in ghostscript or in the postscript generated by gedit and openoffice. Again, please attach a screenshot showing the text in gedit or openoffice to illustrate what the text is supposed to look like.
I'm reassigning this to gedit for now, since it's definitely not an evince problem. If the problem is with ghostscript please reassign accordingly. As for the openoffice problem, I think this is a different problem in openoffice postscript generator, so please file a bug against openoffice with a screenshot of what it is supposed to look like along with the generated ps file.
Well if it's a problem with the generated postscript it's not a gedit problem. gedit doesn't write it's own postscript out manually. It uses the new gtk printing api that Alex and John wrote. Those use cairo and pango I believe. Reassigning to cairo and adding behdad since he has a lot of domain knowledge here in this area that I don't have. Adding Kristian to the cc list, because he can't get himself away from the bug that easily ;-) Maybe a clip mask is getting set to the wrong extents somewhere?
grr, didn't add behdad somehow. Trying one more time...
This is a ghostscript problem, reassigning. I've confirmed that ghostscript-8.15.2-5 renders the document correctly. Also, postscript output from cairo, gnome-print (which is what gedit uses and is what created the attachment in comment #3), and apparently openoffice all has this problem, which suggest that it's independent of the PS generator. Somehow ghostscript gets the bounding box wrong for truetype fonts. There's an upstream cairo bug here: https://bugs.freedesktop.org/show_bug.cgi?id=8180 where it happens for plain English text. From bug 165962 it looks like we tried to use freetype instead of ghostscript itself to render truetype glyphs, and this is what ghostscript-8.15.2-5 does, as far as I can tell. I couldn't reproduce the segfault mentioned there, but I did get a postscript error on the test case attached there. However, using 8.15.2-5 fixed all the glyph clipping problems I saw, including the ones mentioned in the upstream cairo bug. Testing 8.15.2-6; this version backs out the freetype dependency and fixes the problem in 165962 but also correctly renders all the documents where the rawhide version clips glyphs. Between -6 and current rawhide all the changelog says is: "Revert CJKV patch.", which corresponds to svn164:165. I'm curious as to why this patch was backed out, as it seems to fix this bug and a number of other glyph clipping problems, without adding regressions. Looking at ghostscipt upstream bug http://www.cups.org/espgs/str.php?L1831, suggests that it was backed out in svn173:174: svn diff -r 173:174 http://svn.easysw.com/public/espgs/trunk/ |less but that bug report appears to be misunderstood as the CJKV patch actually fixes the problem in the bug (see https://launchpad.net/distros/ubuntu/+bug/50771). Did we back out the patch on the basis on this revert? Unless I'm missing something, I'd recommend we add the CJKV patch back in. Kristian
Tim, ping?
just taking the patch from that changeset makes another problem to deal with umulaute - please see http://www.cups.org/espgs/str.php?L1911 If we use that again, need another changeset for a workaround. I'm not sure if workaround helps this issue. but FYI.
As Akira TAGOH says, we backed it out because it caused other problems. Looks like those problems might have been fixed (or worked around) upstream now. I'll see if I can find out when there might be another release of espgs that we can pick up. [private mail sent]
8.15.3 has been released which supposedly fixes this problem. I will see whether the fix can be easily extracted from it.
So I just tried the CJKV patch with the svn173:174 fix for STR #1911 and am still seeing the regression described in bug #167596. Next thing is to try 8.15.3.
Same thing with 8.15.3. So the regression at issue is bug #167596.
To use CJKV patch completely, we will need to add CIDFnmap* files back to fonts-{japanese,korean,chinese} packages. will test and get it back to you.
BTW the initialization code in gs_init.ps is missing. it should be in gs-esp subversion.
tagoh: please try with ghostscript-8.15.2-9.1.fc6 from dist-fc6-updates-candidate. This contains the change I aim to add for RHEL5 (bug #203712). Have you had a chance to test with the CIDFnmap files added to the three relevant fonts-* packages?
Yes, but it looks like need more works -- current CIDFnmap parser isn't the same as gs7 did. it doesn't support reading other CIDFnmap* from it. Also, the package needs to contain CIDFnmap after that, which is referring to /etc/ghostscript/CIDFnmap*. or you can just contain all font entries in CIDFnmap without referring to CIDFnmap* that font packages will ships.
So we already ship /usr/share/ghostscript/8.15/lib/cidfmap which has: %! % Don't change following line. We should ensure that the original one is surely loaded. (cidfmap.GS) .runlibfile % following lines are for CJK fonts. (cidfmap.ja) .runlibfileifexists (cidfmap.ko) .runlibfileifexists (cidfmap.zh_CN) .runlibfileifexists (cidfmap.zh_TW) .runlibfileifexists and 'gs -h' shows that /etc/ghostscript is already in the search path. Do we just need a patch like this?: --- espgs-8.15.2/lib/cjkv/cjkfnmap.ps.split-cidfnmap 2006-11-17 16:59:21.000000000 +0000 +++ espgs-8.15.2/lib/cjkv/cjkfnmap.ps 2006-11-17 17:03:39.000000000 +0000 @@ -75,10 +75,17 @@ % stack: dict file cidfontname filename|aliasname 1 index type /stringtype eq 1 index type /nametype eq and 1 index xcheck and - 1 index /run eq 2 index /.runlibfile eq or and { + 1 index /run eq 2 index /.runlibfile eq 3 index /.runlibfileifexists eq or or and { % This is an inclusion entry. - pop findlibfile { exch pop } { file } ifelse - 2 index exch .cjkv_readCIDFontmap pop + 0 index /.runlibfileifexists eq { + pop findlibfile { + exch pop + 2 index exch .cjkv_readCIDFontmap pop + } { pop } ifelse + } { + pop findlibfile { exch pop } { file } ifelse + 2 index exch .cjkv_readCIDFontmap pop + } ifelse } { exch dup type /stringtype eq {cvn} if exch { 2 index token not (forward-ported from FC4)
Yes, that's right -- current parser doesn't seem to support even .runlibfile though. so those entirely needs to be backported.
Well, surely it must already support .runlibfile -- that *is* the back-ported patch in comment #21.
Please test ghostscript-8.15.2-9.2.fc6.
Fixed in update: ghostscript-8.15.3-1.fc6