First, apologies to all. I put the tele-con in my calendar without making
the UTC adjustment. As a result, living in what is currently an EDT time
zone (UTC-4), I missed the tele-con by several hours.

There were some questions regarding P0267 raised in the tele-con.

Regarding SG16, Tom Honermann, the chair of SG16, contacted me about doing
a presentation to SG16 regarding text in Cologne. I already agreed to it,
but it was a good point to raise regardless since there definitely is an
intersection (given P0267R9's reliance of UTF-8).

The other question raised in the call was that a "[l]ot of the push back on
earlier versions of P0267 came from Rapperswil -- it would be worth
checking what the issues were that were raised and asking how can we obtain
more agreement."

I reviewed the relevant Rapperswil minutes and I think P0267R9 addresses
all problems that could be resolved. I will address them in turn.

1. Issues were raised regarding input and the fact that certain samples
rely on platform-specific code.

Input is a feature that we have always intended to add only after the
output API has been added. There have been recent discussions about this on
the SG13 reflector. You can view the thread here:
https://lists.isocpp.org/sg13/2019/06/0006.php . If you do not have access
to the SG13 reflector, you should be able to subscribe here:
https://lists.isocpp.org/mailman/listinfo.cgi/sg13 . If that does not work,
please contact Roger.

As for the use of other platform-specific APIs in certain samples (e.g.
cpu_load), these samples are meant to show how users can leverage the
graphics API to perform certain tasks involving 2D graphics. We do not
intend to propose a standard implementation of things such as system
performance metrics. As regards the cpu_load sample, it show how a Standard
2d Graphics API can be used in combination with platform-specific APIs to
create results that may be useful to end users on various platforms.

2. Separability of Linear Algebra and Geometry from 2D Graphics.

Whenever I have been asked about this, I have always replied that I think
it would be great for C++ to have a standard linear algebra library and
then followed up with the statement that I am not the right person to draft
one. I'm not a mathematician. I know linear algebra to the extent that it
is needed for graphics (2D and 3D), but am not an expert in the subject. I
then stated that I would be happy to revise the proposal to use any such
library if someone created one.

There is now a proposal to add linear algebra support to C++:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1385r0.html . One
of the co-authors of P0267, Guy Davidson, is a co-author of P1385. I am
100% in favor of it and very much hope to see it in the STL as soon as
possible. If/when that occurs, P0267 will be modified to use those
standardized types. Until then, the linear algebra types needed for 2D
graphics will remain in the proposal.

I'm much less certain about the need for a geometry library. If such a
library was added, 2D graphics would be modified to use it. But I don't
imagine that one would be useful at this time seeing as I can't think of
any use other than for 2D graphics.

3. Is there a way to implement P0267 cheaply with a permissive license?

A back end that uses Qt can be written fairly quickly, which is available
on all major platforms, and is available under the LGPL 3.0 license. Right
now, the reference implementation provides back ends that use cairo
(available under the MPL 1.0 license) and using Apple's Core Graphics API.
The only major platform missing from the current back ends is Android. A Qt
back end would solve that. Anyone concerned about the Qt LGPL license can
obtain a commercial license from the folks who produce Qt.

I think that addresses concerns about whether it can easily be made
available by all vendors very quickly with a permissive license.

(Note: I am writing a Qt back end and expect it to be available by Cologne
if not before then.)

In the long run, my expectation is that back ends that are more directly
integrated with platforms and their potential graphics hardware
acceleration (e.g. DirectX on Windows platforms and OpenGL/Vulkan for the
other major platforms) will be written. I know how to write such back ends,
but doing so would take up so much time that I could only afford to do it
if someone hired me to do so. (As a side note, in the spirit of full
disclosure, Direct2D and DirectWrite do not publicly expose APIs that would
be sufficient to create an implementation of this proposal. As such, a
DirectX implementation would need to be written either entirely using D3D
or using interop and/or non-public APIs (to the extent they exist).
OpenGL/Vulkan do not have anything similar to Direct2D and DirectWrite in
their APIs. Other libraries exist (e.g. freetype2, fontconfig, and
HarfBuzz) that can provide the text rendering functionality under
reasonable licenses for the platforms they would likely target).

4. Providing portable APIs that can communicate with users of C++ programs

The point was raised that <conio.h> (and later <iostream>) were part of C++
because text consoles were the predominant way of communicating with users
when C++ was created. Now, in the age of smartphones, tablets, and
window-based PCs, 2D graphics is the predominant way of communicating with
users. The fact that C++ has lost the feature of being able to communicate
with users using the predominant way of communication is truly a loss in
functionality in my opinion. The results of this loss are stated in the
section 0.1.1 [io2d.background] in P0267R9, and its effects on companies
looking to hire C++ programmers are reflected in the minutes of the
Rapperswil meeting.

5. Text rendering is hard to standardize.

This is true. We are fortunate that it has already been done. ISO/IEC
14496-22 (available for free from ISO here:
https://standards.iso.org/ittf/PubliclyAvailableStandards/ ), which
standardized the Open Font Format (OFF), the predominant font format in the
world, specifies all of this. The additions of text rendering in P0267R9
defers heavily to that standard. (Note: It's a 600+ page standard written
by professionals in that field.) The existence of that standard made it
relatively easy to add text rendering to P0267.

That said, the text rendering API in P0267R9 is not complete. It is
complete enough to get feedback on, which is why it was included, but there
are known issues in terms of missing functionality that must be included.
P0267R9 specifies it briefly in a note. It is layed out in more depth in
the "Guidance for Reading P0267R9.pdf" document which was posted to the
SG13 reflector and will be added to the SG13 Cologne Wiki. This
functionality was not included because I ran out of time, not because it is
impossible or otherwise impracticle.

6. Some people think that creating a 2D graphics standard API is not worth
the Committee's time.

P0267 was effectively killed in the evening session in Rapperswil. I
accepted this when it happened even though I'm not aware of any precedent
for such an action in an evening session and hope that such a thing never
occurs again.

So why are we still discussing P0267? Because of P1200 (
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1200r0.pdf ), a
paper co-authored by Guy Davidson and six National Body chairs who believe
that a TS based on P0267 should be issued. As a result of that paper, SG13
became an active SG again and is now considering not just P0267 (and other
graphics proposals), but also an audio proposal. And it is open to
additional human-machine interface (HMI) proposals should anyone wish to
propose one.

I believe that the above text addresses the issues raised in Rapperswil.

I am happy to answer any questions or concerns about P0267. Since it was
revived, its review by SG13 in San Diego 2018 indirectly led to the
creation of the Command List API, included in P0267R9.

If you look back, each iteration of P0267 (including its origination as
N3888, followed by N4021, then N4073, from which P0267R0 followed) has
incorporated feedback from previous reviews by LEWG and SG13 as well as
informal feedback from various people.

P0267R9 is not a complete, polished proposal. It still has some TODOs and
other missing bits. It lacks some important features needed for proper text
rendering and mentions those in the document. It is my intent that P0267R10
will resolve all of these issues. My hope is that we will focus on the
newly introduced text rendering API and command list API in Cologne.
Feedback on these will help make R10 better and hopefully allow the
addition of an input API in R11 (if not R10).

Thank you in advance for all of your feedback and I look forward to seeing
you in Cologne!

-Mike