Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Postscript output uses ambiguous font encoding values. Unparsable. | ||
---|---|---|---|
Product: | gsl | Reporter: | dcinege <dcomm> |
Component: | code | Assignee: | Joost Andrae <Joost.Andrae> |
Status: | CLOSED FIXED | QA Contact: | issues@gsl <issues> |
Severity: | Trivial | ||
Priority: | P4 | CC: | issues |
Version: | OOo 1.1 RC3 | ||
Target Milestone: | OOo 2.0 | ||
Hardware: | PC | ||
OS: | Linux, all | ||
Issue Type: | ENHANCEMENT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
dcinege
2003-09-20 05:23:41 UTC
cp->dcinege: there is no warranty on the way we generate postscript output. it is completely unspecified and you must not rely on any implementation detail. it is subject of change without further notice. cp->pl: in 1.0 we generated an ascii subset (HSet1) but in 1.1 we never seem to do but start with subset (HGSet2) for the same characters. Any ideas about that ? dcinege->cp: I should note that the remainder of the 1.1RC3 output still DOES encode based on the ascii char values, for different fonts. (IE Arial) But for this font, for some reason, it does not. (But in 1.0.3 it did) So it's output is inconsistent to itself...and to me that's a bug. As for the output standard, I understand it's subject to change, but in this area in particular, I've never seen postscript output from a word processing type program that didn't refer to a char according to their underlying ascii values in SOME way. (Over the years I've used 3 other programs for check templating before moving to OO. This is the first time It found an unparsable condition.) You'll find encoded characters used for type1 and printer builtin fonts (Times, Helvetica and the like) since they are addressed via their encoding. All TrueType fonts are subsetted, that is only the used glyphs will be put into the new downloaded font - this was so in 1.0.3 also. The difference is that the printing code is not driven with characters anymore but with glyph id's, that is the original Unicode code point is not known at the point the character is output. This is due to complex text layout which makes it possible to print languages like arabic, thai and the like which do not have a simple character <-> glyph correlation. That being said it would be possible to make an exception for ascii, or even better ISO8859-15, but it would require some rework. I'll see if i can do something in the 2.0 timeframe. adjusting component and type according to the announcement on releases (http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7503) this issue will be re-targeted to OOo Later. target fixed in CWS vcl23; this will only work with Ansi1252 characters of course as all other characters have to be mapped into an arbitrary single byte glyph map. reopen ja->pl: please verify in CWS vcl23; output is now ansi encoded for ansi characters fixed JA: verified within cws vcl23 äääöööüüüßßáéç is now used with it's unicode values within the postscript output <E4E4E4F6F6F6FCFCFCDFDFE1E9E7> JA: closing *** Issue 42983 has been marked as a duplicate of this issue. *** |