On 07/22/2013 01:05 PM, Jouni K. Seppänen wrote: > The following message is a courtesy copy of an article > that has been posted to gmane.comp.python.matplotlib.devel as well. > > Michael Droettboom <mdroe-pfb3ainihtehxe+lvdl...@public.gmane.org> writes: > >> I've drafted a MEP with a plan to improve some of the text and font >> handling in matplotlib. >> >> I'd love any and all feedback. >> >> https://github.com/matplotlib/matplotlib/wiki/Mep14 > I'm a bit late to the party
Not too late -- the implementation has barely begun. > , but here are a few thoughts: > > What I see as the biggest problem in the current font-selection system > is its opaqueness. You can attempt to specify a style you'd like, but > it's up to the backend to find the relevant font. The naive user has no > way of knowing which font actually got selected, and no way of knowing > how to modify the parameters to get what they want (except if they > stumble upon the way to specify the full path to a font file). Each > backend can override the font-selection code, so e.g. the ps backend > has an option to use only "AFM fonts", meaning the core fonts built into > PostScripts viewers. Good point. I should add that in the MEP as an explicit example of another case where the font selection needs to be special-cased. > > The subsetting system proposed in MEP14 (reading the font via FreeType, > then rendering or outputting the outlines into the result) would make > backends consistent with each other, as long as the same text engine is > used. Then at least the OO API could have font selection as an explicit > step, i.e. instead of > > ax.text(x, y, s, family='serif', style='oblique') > > you could write > > font = text_engine.find_font(family='serif', style='oblique') > ax.text(x, y, s, font=font) > > and also query the `font` object for what actual font is being used. > (Or would it look more like ax.text(x, y, text_engine.layout(s, font))?) > > If we want to continue support for backend idiosyncracies like > ps.use_afm, I suppose those would need to be parameters to the text > engine. My thinking was that there would just be engine-specific attributes on the font selector, e.g.: font = FontProperties(family="serif", ps_family="Helvetica") and then you can pass this into the regular text engine or the PS AFM-specific one and they would both know what to do. But maybe that needs some more thinking. What I want to avoid is the current situation where things change radically when switching text engines because they *need* to handle fonts so differently. I'd rather make that more explicit -- because I don't think there's any way to make font selection work the same way across all of them. I think that's the assumption in the current design and it's not great. It works fine if you say "give me a sans serif font, I don't care which", but beyond that, the user needs domain-specific knowldege. Honestly, this is a part of the MEP that I think needs work -- I basically threw up my hands as a solution to the problem. Maybe there is a better way. > > ---- > > The approach of subsetting fonts by writing a new Type-3 font in the > PostScript or PDF file would allow supporting any fonts that FreeType > can read, but this would lose hinting information in TTF and Type-1 > fonts. I think we should at least leave open the possibility to embed > the original font (or a directly-derived subset). Yes. But that's not a change from current behavior. We've had subsetting fonts as Type 3 fonts for *years* and no one has complained about the lack of hinting. And we do provide an option to embed the entire original font if necessary (and no reason to remove that). What's new in the MEP is that the subsetting would be based on the freetype API (and thus be able to read virtually any font as input), rather than ttconv (which can only read well-behaved TrueType fonts with Macintosh metadata). This will allow us to support Microsoft-specific TTF fonts (the ones that ship with Windows 7 and 8), OpenType fonts and Web fonts. > > ---- > > The code that parses DVI files from TeX outputs not only glyphs but also > boxes, which are black rectangles used to implement things like the > underscore character and the varying-length part of the square-root > sign. To support this, I guess TextSpan.get_chars should be able to > return not only TextChar instances but also boxes. > Good point. We'll need that for the built-in mathtext renderer as well, for the same reason. Mike ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
