[cairo] fonts and text in ISO C++ graphics library? (Re: Cairo and ISO C++)
behdad at behdad.org
Tue Jan 14 01:04:15 PST 2014
On 14-01-07 05:02 AM, Michael McLaughlin wrote:
> My name is Mike McLaughlin and I'm working with Herb and Jason on the initial
> For simplicity and platform independence, the initial proposal will only
> contain cairo's toy font API.
That sounds about right to me.
> We know that this is inadequate for a number of use cases (e.g. it lacks
> support for RTL languages).
And it doesn't support complex scripts (Arabic, Indic, ...) among others.
It doesn't have to be like that though: it's fairly straightforward to have a
show_text() API that works fine for single-line text. We just need to wire up
a bidi itemizer and harfbuzz in the glue layer. That definitely can be done.
Our reason for including it is that we wanted to
> make sure that there was at least some basic ability to render text. We chose
> not to include anything else because we recognized that font loading and text
> rendering is a complicated area (especially cross-platform) and we did not
> want to risk getting it wrong. I'm hopeful that when the initial proposal is
> published, there will be some discussions about how best to address advanced
> font management and text rendering (something on par with the capabilities
> of FT2 + fontconfig, DirectWrite, etc.) and ultimately one or more proposals
> to implement the results of any such discussions.
> The library is going to include the concept of native handles (something that
> has already been adopted and used with much success in the C++ Standard
> Library's thread class) so that implementers can provide access to
> platform-specific resources. If we can get a 2D drawing library with basic
> text support standardized relatively quickly, I think that would be a great
> achievement even if it means that users who need advanced text rendering need
> to use native handles and platform-specific code to do that until that,
> too, is standardized.
> User fonts are not currently incorporated but it looks like something that
> would be both easy to add and useful to have so I wouldn't be surprised if
> they were added in an amendment. The reason they aren't in the initial
> proposal is because we didn't consider anything beyond the toy font API once
> we determined that anything beyond that would require a lot of thought,
> discussion, and experimentation to get it right.
> On Sun, Jan 5, 2014 at 11:46 PM, suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp
> <mailto:mpsuzuki at hiroshima-u.ac.jp>> wrote:
> Dear Herb,
> When I've heard that ISO C++ committee started the discussion on
> the standardized graphics library, I hoped somebody reminds about
> cairo, so I'm happy to see your post.
> BTW, could you tell me whether the scope of the discussion deals
> with the text and font features? At present, the abstraction of
> the font object in cairo is not complete platform independent;
> cairo has FreeType2, Win32, Quartz and "User Fonts". FreeType2
> (and fontconfig) is a less-platform independent library, but it
> would not be the best solution for the people expecting as a modern
> operating systems should not request the users to locate and access
> the font files directly. The safest set would be "User Fonts"
> which the clients should implement the set of functions to deal
> with the character code, glyph index and glyph data. The font face
> management (e.g. face name <-> font data) should be done out of
> cairo. But I'm afraid that it could be different from what the
> original scope of the discussion was looking for.
> mpsuzuki, JTC1/SC34 member
> On 01/01/2014 11:23 AM, Herb Sutter wrote:
> Hi, my name is Herb Sutter and I chair the ISO C++ standards
> committee. Behdad referred me to this list as the right place to raise
> this question:
> We are actively looking at the potential standardization of a basic 2D
> drawing library for ISO C++, and would like to base it on (or outright
> adopt, possibly as a binding) solid prior art in the form of an
> existing library. You can find a quick summary of goals and
> discussions to date in these two papers:
> As noted in the latter paper, we are currently investigating the
> direction of proposing a mechanically C++-ified version of Cairo.
> Specifically, “mechanically C++-ified” means taking Cairo as-is and
> transforming it with a one-page list of mechanical changes such as
> turning _create functions into constructors, (mystruct*, int length)
> function parameters to vector<struct>& parameters, that sort of thing
> – the design and abstractions and functions are unchanged. This would
> also allow us to track Cairo as it evolves in the future, by
> continuing to reapply the same rules to new updates to Cairo.
> We know about Cairomm but it seems to have languished so we are
> focused on current Cairo as a starting point, even though it’s not C++
> -- we believe Cairo itself it is very well written C (already in an OO
> style, already const-correct, etc.).
> We want to make sure we’re doing this in the right way and with the
> group’s approval, so your feedback would be much appreciated. Also, we
> might want to reuse parts of the Cairo documentation in our
> specification, which we understand is governed by MPL 1.1, and we
> would like to know if this would be all right with your group.
> Thanks, and best wishes,
> cairo mailing list
> cairo at cairographics.org <mailto:cairo at cairographics.org>
More information about the cairo