Bug 461617

Summary: modified Sazanami-Gothic font showing vertical text rendering glitches not seen in the original
Product: [Fedora] Fedora Reporter: Caolan McNamara <caolanm>
Component: openoffice.orgAssignee: Caolan McNamara <caolanm>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: caolanm, fonts-bugs
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-02 09:58:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 473303    
Attachments:
Description Flags
Sample openoffice.org document with vertical text in this font
none
screenshot with what we have in rawhide
none
what I get if I revert to the original upstream font tarball
none
Screenshot on ghostscript
none
testcase that I tried on ghostscript none

Description Caolan McNamara 2008-09-09 14:28:57 UTC
Created attachment 316191 [details]
Sample openoffice.org document with vertical text in this font

Description of problem:
OpenOffice.org documents using vertical text in Sazanami-Gothic show broken glyphs. The spec for this font says

"
# original is http://prdownloads.sourceforge.jp/efont/10087/sazanami-20040629.tar.bz2
# due to Bug#196433, ttf has been modified and the tarball repacked
Source0:       sazanami-%{fontver}.tar.bz2
"

if I locally revert to the original .tar.bz2 from http://iij.dl.sourceforge.jp/efont/10087/sazanami-20040629.tar.bz2 then the rendering look right.

See: http://qa.openoffice.org/issues/show_bug.cgi?id=92671 for discussion about this, and the suggestion that the hacky editing of the font has gone awry.

Attached is a sample document for use with Sazanami-Gothic installed, and screen shots of it with the modified fedora version, and a screen shot with the tarball reverted to the original upstream one

Comment 1 Caolan McNamara 2008-09-09 14:29:45 UTC
Created attachment 316192 [details]
screenshot with what we have in rawhide

Comment 2 Caolan McNamara 2008-09-09 14:30:31 UTC
Created attachment 316193 [details]
what I get if I revert to the original upstream font tarball

Comment 3 Akira TAGOH 2008-09-21 01:22:17 UTC
Thanks for reporting. BTW is Sazanami fonts still default in OOo for Japanese? if yes, that would be better changing the default font to VL Gothic.

Comment 4 Akira TAGOH 2008-10-19 10:34:06 UTC
fontforge reports too much errors/warnings with exporting ttf. probably Sazanami fonts has underlying problems.

Comment 5 Bug Zapper 2008-11-26 03:00:10 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 Nicolas Mailhot 2009-09-23 15:50:40 UTC
It would also be worth testing with the dev version of OO.o, since it is supposed to correct many OO.o OpenType problems

Comment 7 Caolan McNamara 2009-09-24 08:04:05 UTC
This issue is unaffected by the additional opentype support and other OOo-dev changes.

Comment 8 Akira TAGOH 2009-09-24 11:25:26 UTC
just tried the latest fontforge in rawhide to re-export ttf without any updates. I can still see this issue. I'm not really sure what exactly causes this but apparently fontforge has a problem with the default options in exporting ttf.

Comment 9 Caolan McNamara 2009-09-24 14:45:44 UTC
hmm, I also see this using the fonttools ttx, i.e.
ttx -i -a -e original-sazanami-gothic.ttf
ttx -b original-sazanami-gothic.ttf
also generates output which exhibits the behaviour that the original doesn't.

Comment 10 Nicolas Mailhot 2009-09-24 20:37:45 UTC
It would probably be a good idea to notify ttx and fontforge authors about this problem, maybe they can teach their tools to work around such buggy font files?

Comment 11 Akira TAGOH 2009-09-28 12:02:30 UTC
Created attachment 362881 [details]
Screenshot on ghostscript

I still need to investigate further more and this may mislead to get the right thing perhaps but just tried the vertical writing on ghostscript-8.70-1.fc12. and it looks good to me.

Coming questions would be:
1. How OOo render for the vertical writing. e.g. referring the vert table in TTF or anything else
2. How about gs?

just for updates.

Comment 12 Akira TAGOH 2009-09-28 12:04:12 UTC
Created attachment 362883 [details]
testcase that I tried on ghostscript

Comment 13 Caolan McNamara 2009-09-29 15:45:41 UTC
So, on the ttx front I have some findings anyway...
upstream .ttf
$ ttx -l sazanami-gothic.ttf |grep GDEF
    tag     checksum   length   offset
    GDEF  0x00293516       30  3654796
$ od -Ax -j 3654796 -t x1 sazanami-gothic.ttf -N 30
37c48c 00 01 00 00 00 0c 00 00 00 16 00 00 00 02 00 01
37c49c 00 03 35 0f 00 01 00 04 00 00 00 02 00 00
37c4aa

unpacked and repacked with ttx as above and we get...
$ ttx -l sazanami-gothic.ttf |grep GDEF
    tag     checksum   length   offset
    GDEF  0x00293515       30  7701068
[root@Nom tmp]# od -Ax -j 3804688 -t x1 sazanami-gothic.ttf -N 30
75824c 00 01 00 00 00 0c 00 00 00 16 00 00 00 02 00 01
75825c 00 03 35 0f 00 01 00 04 00 00 00 01 00 00
75826a
which also gives the weirdness

If I now tweak the "CoverageFormat" bit (where the two above differ) for the GDEF from Format 1 to Format 2 within ttx then it works fine. e.g.

original .ttf unpacked and repacked with my custom ttx
ttx -l sazanami-gothic.ttf |grep GDEF
    GDEF  0x00293516       30  7701068
od -Ax -j 7701068 -t x1 sazanami-gothic.ttf -N 30
75824c 00 01 00 00 00 0c 00 00 00 16 00 00 00 02 00 01
75825c 00 03 35 0f 00 01 00 04 00 00 00 02 00 00
75826a

So there is likely at least one route to solving this by e.g. extending ttx to support an additional flag like the existing -b which says not to recalculate bounding boxes with another one that says not to recalculate which CoverageFormat is more efficient and turn the changes of bug 196433 into a patch to the .ttx output of ttx. I'll have a poke at this to see if that would work in theory at least.

Comment 14 Akira TAGOH 2009-09-30 02:23:02 UTC
Thanks for analysing. here is more details in TTF spec:

GDEF Header
0000: 00 01 00 00 : Version of GDEF table
0004: 00 0c       : offset to GlyphClassDef table
0006: 00 00       : offset to AttachList table
0008: 00 16       : offset to LigCaretList table
000A: 00 00       : offset to Mark Attachment Class Definition table

GlyphClassDef table
000C: 00 02       : ClassFormat
000E: 00 01       : ClassRangeCount
                  : ClassRangeRecord[0]
0010: 00 03       : Start
0012: 35 0f       : End
0014: 00 01       : Class, 1 = base glyphs

LigCaretList table
0016: 00 04       : offset to Coverage table
0018: 00 00       : LigGlyphCount

Coverage table
001A: 00 02       : CoverageFormat
001C: 00 00       : GlyphCount


In either case, there are actually no glyph definitions in the coverage table. I'm really wondering why it affects to this.
Is it freetype or HarfBuzz bug?

Comment 15 Caolan McNamara 2009-09-30 11:46:47 UTC
I'm now back to very suspicious about OOo itself. Both fontforge and ttx are preferring the type 2 coverage format when saving this font as its more compact in this case that the original fonts type 1 coverage table. Presuming that both ttx and fontforge are re-encoding as type 2 correctly then it would be OOo that's handling them incorrectly.

http://www.microsoft.com/typography/otspec/CHAPTER2.htm has "Coverage Index (GlyphID) = StartCoverageIndex + GlyphID - Start GlyphID" which *plausibly* is somewhere we're going wrong.

Comment 16 Caolan McNamara 2009-09-30 14:04:59 UTC
I think I have this as a bug in OOo after all :-)

It'd probably be a good idea if we were to use ttx to build our modified font so that we could take the original source and made the modifications during our build process to make it transparent what the changes are being made. I might play around with that as a separate thing.

Comment 17 Caolan McNamara 2009-10-02 09:58:20 UTC
available in F-12 as 3.1.1-19.10