[format.string.escaped] example is rendered incorrectly
Closed this issue · 19 comments
https://eel.is/c++draft/format.string.escaped#example-1, in particular the s3 line.
Thanks for the report!
By the way, I'm confused about that s3 line:
string s3 = format("[{:?}] [{:?}]", '\'', '"'); // s3 has value: ['\”, '"']
Shouldn't there be two pairs of [] in the result, given that there are two pairs of [] in the format string?
Yeah that sounds like a bug in the paper.
Edit: was already reported as cplusplus/draft#5751
Others bugs were revealed by an implementor in cplusplus/draft#5751, but not that one. Oh, I see now that they replaced the [] for a comma.
Ah ok, thanks for the link.
@Eelis: tangentially, would you consider setting up a harmonizing family of fonts for your HTML rendition? There are lots of options, but anything where the roman, italics, and monotype have the same contrast and metrics would perhaps make the HTML view even nicer? (I can make some suggestions if you like (and it wouldn't have to be Computer Modern).)
@tkoeppe I see that I currently use Times New Roman for most things, Courier New for code, and Arial for sans-serif. Looks alright to me, and I like using super standard fonts. But if you have ideas about alternative choices that could look significantly better, I'm intrigued. :)
Reopening because now there's still a bad quotation mark in there.
Right, those fonts are pretty poorly matched. Courier New is among the worst, having complely different sizes and contrast (it's too large and too thin). To see what I mean, just compare this against a harmonizing family. For example, DejaVu Serif, DejaVu Sans, and DejaVu Sans Mono. There are many more nowadays (e.g. Noto {Serif, Sans, Mono, Emoji}).
Tried DejaVu and Noto just now, but neither seemed like an improvement over the status quo.
Have you set all the fonts jointly (e.g. body font to DejaVu Serif, code font to DejaVu Sans Mono)? OK, if you don't find it an improvement that's fair enough.
Just for a fully worked example (also adjusting (= resetting) font sizes and line heights, a view of https://eel.is/c++draft/format.formatter.spec in DejaVu:
One difference between the draft pdf and the pages generated by cxxdraft-htmlgen, is that the pdf only has to deal with a fixed page size, and a page size that's quite big. In contrast, cxxdraft-htmlgen tries to make an effort to still look decent at smaller page sizes. That's a challenge though, because the narrower the page, the more often layout problems occur, e.g. section headers overflowing, code blocks overflowing, grammar rules overflowing, table cells overflowing, and so on. Changing to a much wider font (such as DejaVu or DejaVu Condensed) and increasing the size of code increases the frequency with which such problems occur, harming readability.
Oh, it's specifically with width of DejaVu you mind? That's fair enough. It was just an example to show harmonizing contrast and metrics. But you can do the same with an overall narrower font family of course.
Here's a version using Noto, and also with an overall reduced font size to compensate for the different proportions.
Noto 11pt is wider than Times New Roman 11pt, causing the kind of overflows I mentioned. Noto 10pt makes the text smaller and harder to read.
Yeah. We might need an actual narrower font.
The new Roboto Serif is a variable font with a variable width axis. (And to harmonize you have Roboto or Roboto Flex as a Sans, and Roboto Mono as the monospaced font. A bit wild, but that would give something narrow...
We could just re-use the PDF's font(s) for HTML, namely Computer Modern (Mono/Sans/Serif). OTF/Unicode versions can be pulled from various places e.g. ex.1, ex.2.
PDF source looks like so:
How the HTML would look if it got those fonts:
If you're attentive, you will notice a slight discrepancy in the pixels of the '2' glyph between the PDF and HTML for example. This is because the HTML page is rendered on my operating system with autohinting enabled (i.e. a hack for 96dpi computer screens), whereas PDF viewers and e.g. Inkscape generally do not render with autohinting. So please disregard the slight pixel/shape mismatch in the screenshots.
Sounds good. I'll look into it when I get around to it, thanks! (Or feel free to submit a PR.)