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!