Bug 194592 - [Indic] Upper portion of any character is truncated in post script file
[Indic] Upper portion of any character is truncated in post script file
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ghostscript (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
: i18n
Depends On:
Blocks: 203712 FC6Update
  Show dependency treegraph
 
Reported: 2006-06-14 05:27 EDT by Satyabrata Maitra
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version: 8.15.3-1.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-12 11:23:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot (22.79 KB, image/png)
2006-08-31 08:54 EDT, A S Alam
no flags Details
Postscript File (95.71 KB, application/postscript)
2006-08-31 08:55 EDT, A S Alam
no flags Details
PNG file output from ghostscript (98.78 KB, image/png)
2006-09-25 15:21 EDT, Kristian Høgsberg
no flags Details

  None (edit)
Description Satyabrata Maitra 2006-06-14 05:27:13 EDT
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.
Comment 1 Akira TAGOH 2006-08-28 02:26:09 EDT
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.
Comment 2 A S Alam 2006-08-31 08:54:33 EDT
Created attachment 135279 [details]
screenshot
Comment 3 A S Alam 2006-08-31 08:55:40 EDT
Created attachment 135280 [details]
Postscript File
Comment 4 A S Alam 2006-08-31 09:02:10 EDT
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.
Comment 5 Kristian Høgsberg 2006-09-22 14:45:40 EDT
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?
Comment 6 Kristian Høgsberg 2006-09-25 15:21:51 EDT
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.
Comment 7 Kristian Høgsberg 2006-09-25 15:31:18 EDT
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.
Comment 8 Ray Strode [halfline] 2006-09-25 22:11:18 EDT
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?
Comment 9 Ray Strode [halfline] 2006-09-25 22:15:41 EDT
grr, didn't add behdad somehow.

Trying one more time...
Comment 10 Kristian Høgsberg 2006-09-26 22:22:17 EDT
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
Comment 11 Kristian Høgsberg 2006-09-27 14:35:01 EDT
Tim, ping?
Comment 12 Akira TAGOH 2006-09-27 15:55:39 EDT
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.
Comment 13 Tim Waugh 2006-09-28 05:31:33 EDT
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]
Comment 14 Tim Waugh 2006-10-03 09:11:27 EDT
8.15.3 has been released which supposedly fixes this problem.  I will see
whether the fix can be easily extracted from it.
Comment 15 Tim Waugh 2006-10-03 11:02:01 EDT
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.
Comment 16 Tim Waugh 2006-10-03 11:32:58 EDT
Same thing with 8.15.3.  So the regression at issue is bug #167596.
Comment 17 Akira TAGOH 2006-10-20 09:05:39 EDT
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.
Comment 18 Akira TAGOH 2006-10-28 21:12:46 EDT
BTW the initialization code in gs_init.ps is missing. it should be in gs-esp
subversion.
Comment 19 Tim Waugh 2006-11-16 12:38:21 EST
tagoh@redhat.com: 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?
Comment 20 Akira TAGOH 2006-11-17 09:46:59 EST
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.
Comment 21 Tim Waugh 2006-11-17 12:37:39 EST
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)
Comment 22 Akira TAGOH 2006-11-20 22:56:42 EST
Yes, that's right -- current parser doesn't seem to support even .runlibfile
though. so those entirely needs to be backported.
Comment 23 Tim Waugh 2006-11-21 05:22:22 EST
Well, surely it must already support .runlibfile -- that *is* the back-ported
patch in comment #21.
Comment 24 Tim Waugh 2006-11-27 12:04:04 EST
Please test ghostscript-8.15.2-9.2.fc6.
Comment 25 Fedora Update System 2006-12-12 11:14:02 EST
Fixed in update: ghostscript-8.15.3-1.fc6

Note You need to log in before you can comment on or make changes to this bug.