W3C

- DRAFT -

SV_MEETING_TITLE

07 Sep 2011

See also: IRC log

Attendees

Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
ChrisL

Contents


<glazou> Regrets from Tab, BradK, John, Cesar

<glazou> Regrets from Arno

<glazou> lol

<kimberlyblessing> ChrisL, I think you're just using me because I'm an easy target

<glazou> dsinger_: http://www.leonidas-chocolate.com/gianduja.html

<glazou> dsinger_: there is a leonidas store at walking distance (20 meters) from the meeting place...

<glazou> eh

<scribe> scribenick: ChrisL

status of antons ie

bert: my fault, sent a message to the requests but sent it to wrong place

(that was tpac)

ChrisL: I sent a reminder, should be soon

css3 fonts

ChrisL: the ed is much more up to date

jdaggett: prefer to wait a bit untilmore edits made

<dsinger_> Unless it is actively misleading without the edits, let's publish an then again

tpac on sunday or not?

jdaggett: muchprefer we do

plinss: spoke to Susan about that

fantasai: we could meet elsewhere

<dsinger_> Ugh

glazou: confirmed, we will meet Sunday and willsort out a location later if there is no room at the hotel

<fantasai> fantasai: We had talked about meeting elsewhere if the hotel was not available

writing modes

jdaggett: goes back to text-orientation. issue of default
... means for a string of random unichars what is the behavious in vertical with no extramarkup
... non-normative wording recommends but not clear if its normative or not
... some contextualrules. koji published a tableof these
... spoke to eric mueller of adone who said its better for Unicode to have a table

<jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Sep/0003.html

jdaggett: similar but with some important differences

<fantasai> Um, I don't understand why jdaggett is confused, perhaps he hasn't looked at the draft recently. It says very clearly that the orientations are unequivocally *defined* in Appendix C

<fantasai> because that's what he wanted

jdaggett: says to define a categoryfor each to decide the default orientation

<jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Sep/0042.html

jdaggett: differences between erics proposal and current spec

<dsinger_> Isn't material not explicitly marked informative considered therefore normative?

jdaggett: there is also a category called 'use font' which depends on whether the font has vertical metrics. not clear why that is there

<fantasai> dsinger_: That is my understanding.

jdaggett: also some are in basic latin range
... hope koji willadd somethingto clarify if this is important
... Unicode is the right org to maintain this

<dsinger_> Has Koji been asked to explain? Has the Unicode committee been asked?

<smfr> tumbleweed

szilles: support Eric's proposal

<dsinger_> Ok

szilles: Unicode has been aske and asked Eric to do it
... its a legitimate Uniocode activity
... issue of deciding whether its upright is independent of the vertical metrics

fantasai: if there is no alternate vertical glyph, its better to use the horizontal one
... but we classify fonts as having or not having vertical fonts, this is a bad idea because some fonts have verticalmetrics but lack vertical alternate glyphs
... willproduce brackets that dont encase anything, looks all wrong

jdaggett: most japanese fonts that are used in web pages have vertical metrics
... dont see actual fonts that have these faults

fantasai: dounble quotes in Chinese are unified

jdaggett: can't connect thatto your algorithm

fantasai: three categories - upright always, vertical always and depends on font

szilles: then the font is bad and people will stop using it

jdaggett: adding lots of mechanics that are not needed
... issues of fallback too,may hit a Japanese or not Japanese font. fallback fonts are random
... if you are making another proposal, we need to look at that.
... some discussion not on www-style

<dsinger_> But I think that the case where you hoped for a vertical font but got fallback should be handled?

szilles: adobe position is that upright should not be determined by looking in the font. you decide upright or notthen use the font infortmation
... if you correct bad fonts then you break good ones
... not clear there is an immediate need to fix bad fonts

fantasai;author does not always have that opportunity

scribe: common example is em-dashes. often no verticalalternates, but if typeset sideways you get the wrong positioning

jdaggett: we are talking about the default,not what is possible and not possible.
... so why make the simple case complex, authors can solve with markup

fantasai: markup does not fix bad fonts

szilles: thought this onlyapplied if it was set upright

fantasai: correct behaviour is to set them upright and for all fonts to have alternates

jdaggett: if there are cases nt covered by Erics proposal we need to flush them out. Can't do this on the fly

jdaggett; need to record the examples

szilles: put on a wiki

fantasai: Koji and I are making a list of allthe codepoints and their behaviour

szilles: vert feature only applies to upright characters in vertical text
... not to rotated characters

jdaggett: some ascii chars have no vertical alternates,and this sounds as if it is making the alternats on the fly
... synthesising is always problematic.

fantasai: so its a semantic confusion. you think i am synthesisingan upright glyph where I see it as fallback

jdaggett: want to see a clear definition of why its a problem. need specific use cases

szilles: rotation is only one way to synthesise a glyph

fantasai: how else would you do it

szilles: dont want the synthesis to be codified

fantasai: distinction between chars that look upright and ones that must have an alternate
... hiragana miht have a different positioning for example
... but if not alternate, its fine if its missing
... while for parentheses, an alternate is mandatory

jdaggett: in either case it is the same

fantasai: not really

szilles: these are different types of wrong

jdaggett: common pattern in western companies is to develop japanese fonts in China and the shae is known but the patterns are wrong. so the placement of hragana is wrong and looks wrong
... very helpfulto have what you are now proposaing, different from the spec as it is now

szilles: markup to set vertical shoudltrigger the vert feature

fantasai: definition of upright is thatallchars are upright

jdaggett: only apply vert feature to runs of vert text

szilles: want synthesis so only done after upright or not has been determined

jdaggett: please post proposalto www-style

dsinger: good to see a comparison

jdaggett: posted that earlier

dsinger: good to see some more written discussion

jdaggett: there is a lot of data on the list
... but little in responses

szilles: so we have a distinction between the determination phase and the fixup phase
... this is an important result of todays discussion
... dont care if this is updated in the spec first or in a proposal

jdaggett: we need more analysis on the data before updatingthe spec

<fantasai> Zakim: aagg is fantasai

jdaggett: we need to talk about specific characters in specific situations where it breaks in vertical

szilles: please say that on the list

jdaggett: ok

cpsp and text transform

<glazou> http://lists.w3.org/Archives/Public/www-style/2011Sep/0058.html

<glazou> http://www.microsoft.com/typography/otspec/features_ae.htm#cpsp

glazou: fantasai you raised the issue

fantasai: yes.

szilles: thought we were trying to avoid property interactions

<glazou> we lost Chris

jdaggett: cpsp is capital spacing, and in InDesign its enabled if you set all caps on a selection. slightly widens the spacing
... as default spacig is for mixed case
... problem is that applying text transform wont give the effect if text is already in caps. regularly pointed out. should be intrinsic to the font

<jdaggett> http://kltf.de/downloads/ATypI2007-CrossingBorders-kltf.pdf

jdaggett: seep.28 of that ATypI presentation
... slide shows standard spacing, and cpsp, and contextual kerning
... spacing is really intrinsic to the font,not a feature
... not clearif we should support this feature; better to add to font-variant as an exclusinve value to stop people usingwirth small caps. to avoid feature interactions
... hoping to hear more typophile opinions. on the top of my head its not a good idea

fantasai: so tentative resolution is this is not an issue

jdaggett; yes. people can always use lower levelfeatures to tweak this

<glazou> http://lists.w3.org/Archives/Public/www-style/2011May/0602.html

Greek

fantasai: if dropping accents its complicated. its not just 'remove allthe accents'
... unicode tablesare for single letters not for wholewords
... whole words drop accents so does the first letter
... not in Unicode and not doablewith a simpletable. so we shouldnot require it, but we couldallow it

howcome: could so this with a dictionary

glazou;from a users perspective it shouldcertainly be allowed

jdaggett: slippery slope to allow UAs to do their own thing

glazou: we should accept what native Greek users want
... Unicode works with characters and glyphs, not words

szilles: line break rules are word based

fantasai: only one character lookup

<fantasai> szilles, actually, the line break rules are character-pair based

ChrisL: Unicode has some problems withGreek already

<scribe> ACTION: Chris to contact Unicode about the greek upercasingissue [recorded in http://www.w3.org/2011/09/07-css-minutes.html#action01]

<trackbot> Created ACTION-362 - Contact Unicode about the greek upercasingissue [on Chris Lilley - due 2011-09-14].

fantasai: ok great but that wont help this spec in the short term
... preference is to have what is in Unicode as a minimum bar and allow better

jdaggett: concurr with minimum bar, uneasy on extending

glazou: not only browsers render html/css

jdaggett; happyif they hit that minimum bar

glazou: elika you should add both suggestions

jdaggett;dont like the "if and only if" language

fantasai: please post wording proposals

<scribe> ACTION: jdaggett to post wording proposals [recorded in http://www.w3.org/2011/09/07-css-minutes.html#action02]

<trackbot> Created ACTION-363 - Post wording proposals [on John Daggett - due 2011-09-14].

<dsinger> bye

resolution: uas can do better than the Unicode minimum

fantasai please turn my jumbled crap into nice minutes

Summary of Action Items

[NEW] ACTION: Chris to contact Unicode about the greek upercasingissue [recorded in http://www.w3.org/2011/09/07-css-minutes.html#action01]
[NEW] ACTION: jdaggett to post wording proposals [recorded in http://www.w3.org/2011/09/07-css-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2011/09/07 17:04:09 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: ChrisL
Inferring Scribes: ChrisL

WARNING: No "Present: ... " found!
Possibly Present: Apple Bert CSSWG_LogBot ChrisL Hixie Martijnc Microsoft Ms2ger P3 P36 P41 P49 SteveZ TabAtkins aaaa aabb aacc aadd aaee aaff aagg alexmog anne arronei bradk cathy dbaron dsinger dsinger_ ed fantasai glazou gsnedders hober howcome jdaggett karl kimberlyblessing krijnh lhnz miketayl_r miketaylr nimbupani plinss scribenick shepazu smfr stearns szilles trackbot vhardy
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 07 Sep 2011
Guessing minutes URL: http://www.w3.org/2011/09/07-css-minutes.html
People with action items: chris jdaggett

[End of scribe.perl diagnostic output]