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

[suzuki toshiya]

Dear Mike,

Thank you very much for detailed explanation.
I think it is good choice to exclude most font
API from the first scope of the standardization.
In comparison with another candidate, Cinder
(libcinder.org), cairo toy font API would be
less-concrete and smaller set.

Regards,
mpsuzuki

On 01/07/2014 06:02 AM, Michael McLaughlin wrote:
> Hi,
>
> 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.
> Thanks!
> -Mike
>
>
>
> 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.
>
>     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/n3791.html>
>
>         ·http://isocpp.org/files/__papers/N3825.pdf <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 <mailto:cairo at cairographics.org>
>     http://lists.cairographics.__org/mailman/listinfo/cairo <http://lists.cairographics.org/mailman/listinfo/cairo>
>
>