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

Michael McLaughlin mikebmcl at gmail.com
Mon Jan 6 13:02:32 PST 2014


My name is Mike McLaughlin and I'm working with Herb and Jason on the
initial proposal.

For simplicity and platform independence, the initial proposal will only
contain cairo's toy font API.

We know that this is inadequate for a number of use cases (e.g. it lacks
support for RTL languages). 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>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.
> 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
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20140106/0303cb70/attachment.html>

More information about the cairo mailing list