W3C home > Mailing lists > Public > www-style@w3.org > October 2015

Re: [css-fonts] font-weight-adjust

From: Florian Rivoal <florian@rivoal.net>
Date: Fri, 23 Oct 2015 13:54:41 +0900
Cc: Jonathan Kew <jfkthame@gmail.com>, www-style <www-style@w3.org>
Message-Id: <5FE446C2-7EB3-4935-8968-D42F84FDD624@rivoal.net>
To: John Daggett <jdaggett@mozilla.com>

> On 23 Oct 2015, at 13:28, John Daggett <jdaggett@mozilla.com> wrote:
> 
> Florian Rivoal wrote:
> 
> > Also, I am not particularly familiar with font file formats and font
> > container file formats, so maybe this is a silly question, but but is
> > that sufficient? is this fragment identified always sufficient to
> > identify an individual font face down to 1 specific weight?
> 
> Yes, an individual font has a single weight/width/slant.
> 
> > I wonder if there could be for example cases where using this fragment
> > identifier you could pick between italic or normal, or between
> > proportional and monospace, or between serif and sans serif, but that
> > would still leave you with a font file containing a few font faces of
> > different weights.
> 
> The TrueType collection format is is basically a packaging format for fonts, it's extremely simple. There's a header with a tag/version along with an array of offsets to individual fonts within the package. There is no other identifying information.
> 
>   https://www.microsoft.com/typography/otspec/otff.htm <https://www.microsoft.com/typography/otspec/otff.htm>
> 
> Picking from fonts within the package would require parsing the relevant style info for each of the fonts within the package. And platform vendors in practice don't completely agree on the "correct" attribute used for defining things like font weight (!!!). 
> 
> Ideally, some form of unique id or attributes would be included in the package header but it's not in the current version of the format.
> 
> Just to reiterate, no user agent currently supports the loading of webfonts contained in TrueType collections.


Hi John,

Thanks for the answer.

If I am understanding you correctly, the currently defined mechanism is theoretically sufficient to narrow down to a single font (including weight), and would therefore allow us to solve the problem I raised, BUT the reality of implementations mean that in practice it would not actually work,  and near term prospects about that improving are slim.

If that's what you're saying, then it sounds like a different mechanism (for example, but not necessarily font-weight-adjust) might have a better chance of working.

If that's not what you're saying, I am afraid I missed your overall point.

So just to clarify:

* Do you agree what allowing authors to pair fonts based on numerically different but visually similar font weights is a desirable thing?

* Do you think the currently-specified-but-not-implemented solution based on fragment identifiers will solve the problem?

* If yes, what are the road blocks to getting it implemented?

* If no, do you think something like font-weigth-adjust has a better chance, and if not, any idea about what would?

 - Florian
Received on Friday, 23 October 2015 04:55:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:57 UTC