- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 15 Feb 2013 14:07:30 -0800
- To: "www-style@w3.org" <www-style@w3.org>
CSS3 Fonts
----------
- Reviewed updated wording for case-sensitivity of font name matching.
- Discussed use of OpenType language tags
- Discussed use of OpenType script tags
- Discussed italic synthesis in vertical writing -> open issue.
- RESOLVED: Publish WD of CSS3 Fonts
====== Full minutes ======
Overview of Sizing Issues
-------------------------
SimonSapin: Issue discussed at TPAC wrt multi-col
SimonSapin: Algorithm there has an idea of an unknown "available width",
and I think it doesn't make sense
SimonSapin: I tried to talk with Håkon and Bert, via email, F2F
SimonSapin: but seems we don't understand each other
glazou: Seems like adding to agenda is a good idea
szilles: Would also like to add exclusions update to agenda
SimonSapin: Related issue is that we have two different definitions
for min-content and max-content
SimonSapin: One is sizing, and one in box module, and they are not compatible
SimonSapin: Discussed at TPAC... but still have two.
<TabAtkins> plinss: I'll be back in a sec, but when jdaggett is done,
I'd like to go through the remaining Counter Style issues
and request LC.
Fonts
-----
jdaggett: First topic is case-sensitivity of font family names
jdaggett: Talked about this yesterday
jdaggett: I put last night wording into spec to define the exact algorithm
to be used
<jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-family-casing
jdaggett: Would like to take a second to resolve on this
jdaggett: Points at default caseless matching algorithm in Unicode spec
jdaggett: You case-fold each string
jdaggett: Use case mappings defined by C/F statuses in CaseFolding.txt
jdaggett: Noted there is no normalization, no locale-specific behavior
jdaggett: Another paragraph explains to authors where they should be careful
jdaggett: Most people won't be affected
smfr: Maybe 2nd paragraph should be a note
fantasai: Think the last sentence of 1st paragraph should be a note
jdaggett: Want to make sure implementers don't use the wrong pre-written
methods
TabAtkins: Pulling it out into a note would actually make it more obvious
fantasai: The normative requirements are already expressed in the paragraph,
above. You're just pointing out that it's easy to screw up; this
isn't a normative requirement, it's informative helpful advice
jdaggett: Implementations MUST NOT use platform routines that they don't
understand.
[discussion of normative, informative, notes, etc]
jdaggett: Another issue is wrt default [?]
<jdaggett> http://dev.w3.org/csswg/css3-fonts/#language-specific-support
jdaggett: This deals with language-specific features
jdaggett: Question is, whether UAs should by default always use the default
system, or use heuristics to guess language
fantasai: You defer to the "document language" rules.
fantasai: If it's unknown, use default. Don't guess
jdaggett: HTML5 explicitly says that if it's not specified, it's unknown.
[...]
jdaggett: So if it's not known, what do we do?
fantasai: Is the language a required param to the API calls?
jdaggett: No.
fantasai: Then don't pass a language.
fantasai: If the author wanted lang-specific features, should have put
a lang tag
<SimonSapin> HTML "language of a node"
http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#language
...
[discussion of mapping ISO lang codes to OpenType lang systems]
jdaggett: For most things, you can map. If you want to override, you can
also override
Glenn: ... script ...
jdaggett: This is given by character code
glenn: Opentype Indic have two scripts defined, one for older tables and
one for newer tables
glenn: Since we don't have a way for authors to define script specifically,
we have a gray box here..
glenn: I would suggest treating the whole problem space is
jdaggett: So define default script as well as default language?
glenn: You need three tags to generate the tables that apply
glenn: script, language, feature
jdaggett: We have a set of properties dictating...
glenn: For a given set of features, leaves script and language as parameters
glenn: If you want to fully handle this mapping, then you need to define
all three of these
glenn: Do you have language for dealing with script tag?
jdaggett: what's explained to me is that in general, script tag can be
inferred from the codepoint
jdaggett: Some issue with different versions of indic, but for given
implementation, you're picking one and using that one
jdaggett: Using one or the other
glenn: I'm aware of one implementation, because I did it, in XSL:FO,
allow to specify script identifier based on ISO script
identification system
glenn: So I happen to implement the ability to allow author to specify
variants in order to select between old indic vs. new indic
glenn: If you look for indic fonts, some built for first version, some
for second, some to support both
jdaggett: Those tables can be looked up
jdaggett: You're sort of overspecifying by pushing out into author space
glenn: Just want to make sure script tag mapping is discussed
jdaggett: I thought it was just an implementation detail, didn't need
to be author-facing
jdaggett: Think I might leave this open, since nobody else is speaking up
glenn: I agree with fantasai that you should defer to document language
at first order
glenn: We should make sure there's a well-defined mapping between the
tag sets
glenn: Also begs question of lang tags for non-OT fonts, not sure we
need to get into that
jdaggett: Think we need to make sure it works for OT, implementers can
fill in the dots for other formats.
fantasai: Would like to point out
"Users agents are required to infer the OpenType language
system from the value of the ‘lang’ attribute"
fantasai: Should just defer to document language, not specify how it's found.
<Bert> -> http://www.w3.org/TR/selectors/#lang-pseudo
Selectors text about what is an element's language
<jdaggett> http://www.w3.org/Style/CSS/Tracker/issues/70
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2008Sep/0197.html
jdaggett: I went in to fonts spec and put in prose to handle all the
cases, but never cleared out the issue
jdaggett: Has to do with certain combinations of say question marks,
what the semantics of that are
jdaggett: In the spec, a number of statements about this
jdaggett: Was a conflict with the way the syntax spec was worded, but
that's ironed out before lunch
jdaggett: So, unless anyone sees anything here, I'd like to close this issue
jdaggett: Can always raise another issue if there's something specific
to handle
jdaggett: Think we've fixed all the problems in this issue
SimonSapin: Think Syntax solves the parsing-related issues
dbaron: Might be worth sending something to Zack
RESOLVED: Close ISSUE-70, ping Zack about this
<jdaggett> http://www.w3.org/Style/CSS/Tracker/issues/71
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2008Nov/0077.html
jdaggett: Spec now has prose to talk about this
jdaggett: Gecko implementation doesn't implement 'unicode-range', so
part of reason for difference in behavior [...]
jdaggett: Think most issues have been dealt with in the spec
jdaggett: Can open new bugs if more specific things are found
fantasai: if dbaron's happy, I'm happy
dbaron: Fine with closing it. May some point look at the text and comment
jdaggett: Font loader issues, but defer that... want WebApps people to
comment on some of those things
jdaggett: Other than the language issue, I did make one change...
[some discussion about error handlers]
jdaggett: You have to load content, and start laying it out, to assess
whether you need to download a font
jdaggett: Could start loading a font via JS, but, then that's your own
problem
jdaggett: Is there a scenario you're concerned about?
glenn: Is there a way to register to handler using onerror attribute?
jdaggett: Yes, there are both event handler attributes plus you can use
the event handler name
glenn: So element directly attach to font loader, would that be body?
jdaggett: document
jdaggett: This is all in the spec
<jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-style-matching
jdaggett: Section I want to look at is cluster matching
jdaggett: I put in some wiggle room for specific scenario that sometimes
occurs
jdaggett [quotes spec]
jdaggett: This is a compat issue with the way Arial has implemented
Arabic in the past
jdaggett: Where they have Arabic glyphs in the default face, but not
the italic face
jdaggett: So if you say italic Arial, you get fallback in some browsers
jdaggett: This allows creating synthetic italics
jdaggett: Avoid searching all faces
jdaggett: The added wording, "The only exception ..."
Bert: Default face is the roman face?
jdaggett: What you would select if you had all font properties set to
initial value
jdaggett: Unless there's other issues to bring up, would propose
publishing another WD
jdaggett: Was hoping this would be LC, but I'm uncomfortable with the
way font loader is right now, and want WebApps people to look
it over first
jdaggett: It's an unusual section for a CSS spec b/c defines API with
scripting behavior
jdaggett: So would like to have other people review it
jdaggett: But that is my intent, review things, then go to LC
jdaggett: Hopefully within this month
fantasai: There's an issue raised on italics and vertical text that
probably warrants some discussion as well
jdaggett: Think we shouldn't deal with that in this level
jdaggett: From your post, Koji, don't see that there's a clear desired
behavior
<jdaggett> http://koji.ec/archives/7
jdaggett: In vertical text runs, when you say "italic", most Japanese
fonts don't have an italic face, so what is produced is a
synthetic oblique face
jdaggett: There were two issues in the mail he wrote
jdaggett: One is, what is the right way to do synthetic italics for
Latin in vertical
jdaggett: UAs always oblique to the right. If not right for RTL, could
add ways of obliquing to the left
jdaggett: Tricky one is what to do about vertical text runs, where the
obliquing is distinctly different
jdaggett: If you look at the picture
jdaggett: 1 is what you get by default
jdaggett: different processors will give you different results, depending
on what you want to do
jdaggett: I think Koji said IE10 does 6 and Webkit does 8
jdaggett: From my perspective of just defining what italics should map
to, I think 8 is correct
jdaggett: However, maybe patterns in Japanese publishing where e.g. 3
or 4 are considered the norm
jdaggett: However, I think they require a different property to solve
correctly
jdaggett: Might be a good feature to allow shear transforms on individual
glyphs
jdaggett: But don't think we should do this in this level
jdaggett: Fact that there are 8 different renderings
jdaggett: Shows there is a deeper issue, can't be solved by us declaring
which one is right
jdaggett: Can take an action to get more opinion on this
jdaggett: Don't think we'll get a good sampling of opinion on www-style
plinss: Where do these renderings come from?
Koji: I did it by transform
Koji: This picture is generated by transforms
Koji: But tested what actual results are in other implementations
jdaggett: Problem in spec is inconsistency among browsers, not sure we
should be looking at other implementations
jdaggett: Koji says we should define what synthetic italic looks like
plinss: Is italic used with japanese glyphs?
jdaggett: Not common, but it happens
jdaggett: For Japanese text, if you have italics, and don't oblique it,
people file bugs
plinss: Is it every correct to oblique the text?
jdaggett: If there's a pattern of text obliqued, should investigate/do
something about that
jdaggett: but not for this level
<dbaron> to my eyes, the difference between 2 and 8 is very subtle
<dbaron> (but I do now see it)
jdaggett: I would like more evidence from printed matter that there's
one pattern that's always used
fantasai: CSS3 Fonts requires synthesizing italics, question here is,
if used in vertical text, then what do you synthesize?
jdaggett, szilles: just leave it undefined
jdaggett: Disagree that this blog post is enough to make a decision on
the right default
fantasai: Even if we add a property for this, what would be the initial
value?
dbaron: Experimentation might lead to a bunch of UAs being willing to
switch to another's behavior because it's better.
jdaggett: I'll see if there's more published examples of this being used
consistently, but unless that comes back with a solid answer
of "you always do this"...
szilles: Also have problem that this is Japanese, what about Chinese
fantasai: The preferred slant is derived from the more cursive forms of
Han characters, so would be consistent with Japanese.
...
koji: If I specify italic, want consistent behavior across browsers.
jdaggett: If there's variation...
koji: There is variation in typographic world.
koji: Pick an interoperable consistent default behavior.
jdaggett: It's not a commonly used feature. Might be just accident of
implementation.
koji: Can add features in future. Want the baseline behavior to be consistent.
koji: My preference is to use 6, because it's what word processors do
and people are used to it
jdaggett: Would prefer not to standardize on what a publisher would not do
koji: Publishers want more controls, fine to do in Level 4
jdaggett: Think this needs more research
fantasai: Assume there is a variety of needs. What is the default?
szilles: It's UA-defined.
kawabata-san and koji are not happy with this
kawabata-san: Is there a difference in slanting between LTR or RTL?
jdaggett: Today there is not. Could argue that this is not ideal behavior.
jddaggett: Existing behavior for synthetic obliques is consistent.
glenn: italics don't apply to Arabic anyway
jdaggett: It's an artifact of word processors
fantasai: Some precedent for italics in Hebrew though
fantasai: Following the logic of RTL, where synthetic slant is always
consistent, why not make writing mode also stay consistent.
koji: I'm happy not to make conclusion here, happy to publish WD, as
long as this is kept as an open issue.
<dbaron> the right side of http://www.huji.ac.il/ shows what looks to
me like Italic style in Hebrew
<fantasai> RTL italics discussion: http://typophile.com/node/49385?page=2
<dbaron> (and it's an image, too)
<fantasai> Chinese mixing fonts in Roman/Italics pattern:
http://fantasai.inkedblade.net/style/scans/Princeton%20East%20Asian%20Library%20-%20ZhongGuoYin__Xue%202005.4%20001.png
RESOLVED: Publish WD
jdaggett: Please review the draft, particularly wrt functionality
szilles: Meaning correct definition of the functionalities there, not
what's missing
fantasai: No new features. But if things are unintentionally undefined,
should be an issue
<jdaggett> fantasai: that's a simple mixing of brush styles
<jdaggett> fantasai: comparing it to roman/italic is an oversimplification
<jdaggett> feedback on faux oblique from nat at adobe:
<jdaggett> In my opinion 斜体 is totally different from italic, or even
oblique, in usage and applicability to Latin typographic
convention.
<jdaggett> "In InDesign we keep them totally separate."
<jdaggett> "There is no italic in Japanese, no need to faux oblique with
Japanese using slant, in fact only slanting is wrong, so
just don't do it."
<jdaggett> "Use 斜体 instead which scales, rotates, and shears with
precise settings."
<koji> I agree with Nat. The point here is, if publishing industry doesn't
need italics at all, and if all word processor vendors/users requires
it, why don't we suffice word processor users in level 3, and pursue
publishing industry in level 4?
<jdaggett> if there's consistent behavior that is in common use then we
can use that
<koji> An example HTML file at http://dl.dropbox.com/u/8812114/italics-vertical.htm
<koji> jdaggett: yes, I'll collect actual examples from word processor
market to get to you
<jdaggett> we need actual use cases from users
<jdaggett> not just testcases that use the feature
<br type="tea"/>
Received on Friday, 15 February 2013 22:08:01 UTC