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