[cairo] fonts and text in ISO C++ graphics library? (Re: Cairo and ISO C++)

suzuki toshiya mpsuzuki at hiroshima-u.ac.jp
Sun Jan 5 20:46:37 PST 2014


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.

Regards,
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:
>
> ·http://isocpp.org/files/papers/n3791.html
>
> ·http://isocpp.org/files/papers/N3825.pdf
>
> 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,
>
> Herb
>
>
>



More information about the cairo mailing list