W3C home > Mailing lists > Public > www-style@w3.org > May 2013

Re: [css-fonts] definition of synthetic oblique within the 'font-style' property definition

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 10 May 2013 15:42:53 -0700
Message-ID: <518D77ED.3060606@inkedblade.net>
To: www-style@w3.org
On 05/06/2013 11:26 PM, John Daggett wrote:
>
> There's currently one remaining issue outstanding against the CSS3 Fonts
> spec, Koji Ishii's issue related to how italics are synthesized within
> vertical text runs containing a mixture of orientations.
>
> Koji's original post:
> http://lists.w3.org/Archives/Public/www-style/2013Feb/0121.html
>
> Koji's blog post (Japanese):
> http://koji.ec/archives/7
>
> Discussion at Tuscon F2F:
> http://lists.w3.org/Archives/Public/www-style/2013Feb/0391.html
>
> [...]
>
> I've changed the definition of 'font-style' to give a more precise
> definition of synthetic oblique faces:
>
> Old text:
>
>  # If no italic or oblique faces is available, an oblique face can
>  # by synthesized by rendering the normal face with a sloping
>  # transformation applied.
>
> New text:
>
>  | If no italic or oblique face is available, oblique faces can by
>  | synthesized by rendering non-obliqued faces with a right sloping
>  | transformation applied. When synthesizing these faces, the
>  | transformation should apply to all glyphs in the same way and not
>  | vary based on codepoint or due to horizontal or vertical line
>  | orientation.
>
> This matches current implementations for horizontal text.  For
> vertical text, this is not the behavior of IE10 but it is what
> Webkit does.
>
> We could work on adding new properties to the CSS3 Fonts spec but
> I don't think that's a great idea, there isn't a huge need for this.
> We should figure out at some point how to support this functionality
> cleanly.

Koji and I agree that a feature for skewing characters, as used in
pure Japanese typography, is a separate, new feature and should be
handled in level 4.

However, for this level we disagree with the definition you propose.
Koji has written up a very good explanation of the options and which
makes the most sense. Please see
   http://koji.ec/archives/7
and particularly
   http://koji.ec/archives/32
This points out that to use the type of skew you are proposing
(top side skewed right), there are many problems that are created,
with regards to spacing, slant consistency, and glyph correctness;
whereas to use the type of skew in IE10 (right side skewed down),
we can have a simple solution that works consistently in all cases
and still solves the basic use case.

On 05/09/2013 John Daggett wrote
<http://www.w3.org/mid/1019912648.14386361.1368162007541.JavaMail.root@mozilla.com>:
> A fair amount of the discussion focused on Webkit rendering bugs and
> the need to have some special form of obliquing for synthetic italics
> in vertical text runs.  Whatever this proposal is, it really needs to
> be spelled out.  From the talk on the call it sounded like synthetic
> italic rendering for vertical text would vary based on glyph
> orientation, codepoint, and font features available.
>
> For someone implementing the CSS property 'font-style', when that is
> applied to vertical text runs how are synthetic italic glyphs
> rendered?  What are the conditions that affect the rendering?  Do they
> affect the rendering of font families which contain italic faces (e.g.
> Meiryo)?  Is the rendering behavior different based on codepoint (e.g.
> emdashes) or font features (e.g. vertical alternates)?

As for how the synthesis for font-style should work, here is my
proposal:

   a. For characters that are missing a vertical alternate glyph, one
      is assumed to exist with the same shape as the regular one.
   b. Italic/oblique regular glyphs (non-vertical alternates) are
      synthesized with a clockwise skew in the horizontal dimension.
   c. Italic/oblique vertical alternates (both real and assumed)
      are synthesized with a clockwise skew in the vertical dimension.

There are no codepoint-specific rules, nor are any needed. We are,
exactly as you require, synthesizing a font face without regard to
how the individual glyphs will be typeset, and this synthesized font
face is then used as input into the font selection algorithm exactly
as if it were a real font.

Let me know if this works for you.

~fantasai
Received on Friday, 10 May 2013 22:43:20 UTC

This archive was generated by hypermail 2.3.1 : Friday, 10 May 2013 22:43:23 UTC