Feature/typst font weight & style

[gordonwoodhull]

#10516 points out that we don't support font-weight or font-style in our translation from CSS properties to Typst properties.

We should. Here they are!

Filing as draft because

1. The tests are in the feature-format matrix, which we don't run automatically.
2. Not sure whether to put this in 1.8 or 1.7

[cderv]

Not sure whether to put this in 1.8 or 1.7

It seems to be working and low impact so I would say ok for 1.7, as I don't like shipping with missing things we know how to do. The other brand local font stuff for HTML is something I would have like to have;

But it may be too late in our release phase schedule...

[cscheid]

We can consider a 1.7 backport, but I think we've been stable enough with bugs that I'd like to try and make an official release by the end of the week, so to 1.8 it would go.

[cderv]

@gordonwoodhull I was playing with TYPST CSS for a presentation, and I remember this. Is this ready to merge ?

[gordonwoodhull]

I think so! Let me give it another look and I’ll merge this afternoon.

[gordonwoodhull]

TIL that most of the font weight names are actually not standardized in CSS, except for "normal" and "bold". This helps explain why this has taken some iteration.

(I was wondering if we should support "heavy" as a synonym for "black" and it seems there isn't any good answer to that.)

Anyway, I think this is good to merge. I'd like to figure out how to get the feature-format matrix tests running regularly, or else move them into the smoke tests. But that can wait.

[cderv]

I'd like to figure out how to get the feature-format matrix tests running regularly, or else move them into the smoke tests. But that can wait.

Let's schedule some time to work on that together. I'll note that for me as 1.8 work on our CI update.

[cscheid]

(I was wondering if we should support "heavy" as a synonym for "black" and it seems there isn't any good answer to that.)

My direct answer is "yes, I think we should". But let me give a longer answer in the context of the complexity with accumulate with these decisions.

Intentionally or not, we've had a philosophy emerge in Quarto which is "we will do what the user expects". I think it's a good thing, but it makes debugging harder than it otherwise would have been. It makes me wonder if there's a something we can design in our code that would alleviate these concerns.

For example: right now, our logging infrastructure is used sparingly and inconsistently. I wonder if it would be productive to promote this infrastructure to "instrumentation", so we would always write the "info" or "debug" printouts to a file in the .quarto directory. Then, we could have a "quarto report-diagnostics" command that produces a report (human-readable, machine-readable, or both) of everything that was captured in the logs. We could add this to our bug reports and we could create tooling to filter and test against.

In this specific case, our code could make the translation of heavy to bold, but we would add a note that would attest to that translation to the logs, so that we could both detect when it happened, and test whether it does in our test suite.