|
2009-09-18 02:08
|
Scribus 1.33.13svn outlines.png (47,372 bytes) |
|
|
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. |
|
|
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...] |
- Anonymous
