Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Font substitution incorrectly prefers font name over glyph avalibility | ||
---|---|---|---|
Product: | gsl | Reporter: | sforbes <xslf> |
Component: | code | Assignee: | AOO issues mailing list <issues> |
Status: | ACCEPTED --- | QA Contact: | |
Severity: | Trivial | ||
Priority: | P3 | CC: | alan, issues, kaplanlior, yba |
Version: | OOo 1.1 Beta2 | ||
Target Milestone: | AOO PleaseHelp | ||
Hardware: | PC | ||
OS: | Linux, all | ||
Issue Type: | ENHANCEMENT | Latest Confirmation in: | --- |
Developer Difficulty: | --- | ||
Issue Depends on: | 26679 | ||
Issue Blocks: |
Description
sforbes
2003-06-16 18:25:43 UTC
DL->HDU: Could you please takeover? . Accepted. At least for glyph fallback this should be done. Selecting the best font for "font fallback" using fixed lists of suitable fallbacks is already implemented. The seemingly related problem of selecting the best font for "glyph fallback" is much more difficult though. E.g. what is the cultural equivalent of a Sans Serif font in Thai? What is the best glyph fallback font when "Comic Sans" or "Fangsong Ti" are selected but Hebrew characters are used? The problem is to find a font with the same style, that does contain the glyphs that are missing in the selected font. The current approach is to make the text readable ignoring stylistic mismatches, by using a fixed list of glyph fallback fonts. The next step will be to use fixed lists for the most important font. This will later be improved by using panose info to better match fonts. A problem is that panose matching is mostly designed for Latin matching. The best method avoid all this trouble is of course to use a) a font suitable to the text b) to improve the platform's fonts: a font that says: I'm like X on platform Y it should also try to be as compatible as possible to X. adding dina as cc according to http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=7690 this issue will be set to OOoLater Hi hdu, Regarding glyph fallback: You mentioned that the current approach is to make the text readable ignoring stylistic mismatches, by using a fixed list of glyph fallback fonts. Could you tell me where in the code this is implemented? Regarding font fallback: You mentioned that if a font is not found, a fixed list of suitable fallbacks is used. Is this done through VCL.xcu? Is it possible in the current scheme to make a choice based on which font is missing? That is, if the imported document uses "Tahoma" and "Arial", I can fall back to one font for the Tahoma text, and a different font for the Arial text? If so, where can I find this implementation in the code? Thanks, Alan Hi, the font fallback stuff is an area that needs a lot of work invested in it. The old infrastructure was very inflexible and prevented a lot of improvements. The new infrastructure is being implemented in the fontlists* child workspaces... 1) search for FALLBACKFONT_NAMELIST in vcl/source/gdi/outdev3.cxx Yes, I know the algorithm to find good glyph fallback fonts has a lot of potential for improvement. 2) yes, mostly through VCL.xcu, but if there is no match also using stylistic info, e.g. font weight from the Font structure in vcl/inc/font.hxx, eventually also extracting some stylistic info from the font name, e.g. "Serif" 3) yes, just use VCL.xcu to add specific fallback fonts for Tahoma or Arial the actual code to do this is in vcl/source/gdi/outdev3.cxx in the method ImplDevFontList::ImplFindByFont(...) Have fun... Is this issue still relevant in 2.4.0 ? Reset assigne to the default "issues@openoffice.apache.org". |