View Issue Details

IDProjectCategoryView StatusLast Update
0008439ScribusImport / Exportpublic2009-09-22 07:22
Reporterfloid Assigned Tojghali  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionduplicate 
Platformamd64 LinuxOSUbuntuOS Version9.10a-something
Product Version1.3.3.13svn 
Summary0008439: PDF: Font exported as outlines 'subtracts' areas with kerned overlap (CJK?)
DescriptionI noticed unusual behavior letting Scribus automatically convert text in a Korean font to outlines as part of PDF export. Areas of overlap in the subcharacters - I'm still learning the terminology for Korean type, but aren't these a single 'precomputed' glyph in the font anyway? - appear subtracted/negated when they should remain filled/dark.

A picture is worth a thousand words, and one is attached - a screenshot from Adobe Reader 7.0.8, also seen with recent evince etc.

My project was a business card, and it would require a magnifying glass to notice, but this could be a headache on a poster.
Steps To ReproducePaste in some Korean (Hangul) text- for instance the triglyphs in the example are ??, set same in Baekmuk Batang Bold, then export a PDF, choosing to embed all fonts from the "Fonts" tab and accept Scribus's decision to export the non-latin* font as outlines.

*Or because they're really OpenType? I haven't checked which flavor of TTF they actually are.

It appears the Baekmuk fonts are available directly here - http://kldp.net/projects/baekmuk - while I'm using the Ubuntu package in one of their main repositories.
Additional InformationThis may already be fixed, as I'm simply trusting Ubuntu's pick of Scribus 1.3.3.13svn to be the "-stable" version, but I couldn't find a bug that resembled it so figured I'd point it out. Perhaps it requires a rare condition in the source font to trigger it?

Good tests that I have not performed would be to see if similar "Batang"-style fonts (e.g. "UnBatang"), or overlapped latin characters (negative tracking), turn up the same bug if converted to outlines on export.
TagsNo tags attached.
Patch

Relationships

duplicate of 0004564 closedavox PDF Export: Subsetting of OTF fonts (TTF variant) as true TTF subsets in PDF version < 1.6 

Activities

2009-09-18 02:08

 

Scribus 1.33.13svn outlines.png (47,372 bytes)   
Scribus 1.33.13svn outlines.png (47,372 bytes)   

jghali

2009-09-21 19:50

administrator   ~0022507

By design in 133x. That won't change as this stage of 133x life. Fonts with more than 2048 glyphs are automatically outlined as embedding the whole font :
1) is usually totally unnecessary
2) would make pdf file much bigger

1.3.5+ uses a better approach and export subsets those fonts as Type3 font. There are also other opened feature request for true TrueType subsets.

floid

2009-09-22 01:02

reporter   ~0022511

For documentation/clarification:

1) Whups, when I said "Baekmuk Batang Bold" I meant "UnBatang Bold" - lost track of which I had actually used in the document. No bold variant of "Baekmuk Batang" even exists on my systems, and regular Baekmuk Batang doesn't overlap outlines so doesn't reproduce it.

2) Having realized that... In 1.3.3.13svn, converting the text box to outlines directly within Scribus produces the "'xor' on overlap" behavior right in the document. This is because the default "fill rule" for the "shape" is "Even-Odd" ('xor'? or 'negate only on even numbers of overlaps?') instead of "Non Zero" ('inexclusive or,' stay filled on overlap no-matter-how-many-overlaps).

So the fix/workaround/documentation is:
If you're going to be using outlines for some reason, do your conversion before going to export and check to be sure the "fill rule" for each "shape" is what you want.

I haven't figured out how to apply this to an entire selection at once, since it seems it'll only apply to the nearest 'shape' ('outline drawing'? 'used-to-be-a-character') in a selection containing many. It seems the 'properties' will only be applied to the one nearest the cursor in a mass selection, but I've probably missed some subtlety about selecting - just like I missed the 'fill rule' until now. :)


Smart subsetting would make this a nonissue in the common case, yes, glad to hear it's already baked! [As such, you can close this again, just wanted to share the information after puzzling it out...]

Issue History

Date Modified Username Field Change
2009-09-18 02:08 floid New Issue
2009-09-18 02:08 floid File Added: Scribus 1.33.13svn outlines.png
2009-09-21 19:50 jghali Note Added: 0022507
2009-09-21 19:50 jghali Status new => resolved
2009-09-21 19:50 jghali Resolution open => no change required
2009-09-21 19:50 jghali Assigned To => jghali
2009-09-21 19:51 jghali Status resolved => closed
2009-09-22 01:02 floid Note Added: 0022511
2009-09-22 01:02 floid Status closed => feedback
2009-09-22 01:02 floid Resolution no change required => reopened
2009-09-22 07:22 jghali Relationship added duplicate of 0004564
2009-09-22 07:22 jghali Duplicate ID 0 => 4564
2009-09-22 07:22 jghali Status feedback => resolved
2009-09-22 07:22 jghali Resolution reopened => duplicate
2009-09-22 07:22 jghali Status resolved => closed