See also: IRC log
<trackbot> Date: 11 July 2013
<krit> argh
<krit> ScribeNick krit
<heycam> ScribeNick: krit
<heycam> http://lists.w3.org/Archives/Public/www-svg/2013Jul/003.html
heycam: text chaper doesn't say how they affect the SVGDOM
<nikos> /me had a blank. what's the passcode?
heycam: explains mail of link
ed: for text computed length, not
sure. you give textlength by setting text length
... not sure, but we should not return that value
... you want computed thing
heycam: should we have different values for text substring length?
ed: hm
... substringlength, how does it work?
... look
... same as textcomuputelength but not all the length
heycam: yes, should work on scaled glpoh?
s/glyoh/glyph/
heycam: tesxt comp length the only one that differs
ed: should we have two dfferent methods?
heycam: maybe?
ed: haven;t used substringlength that much, so don't konw
heycam: have no strong feeling
ed: what do UAs do?
heycam: doing it right now
... FF substrlength works on original length
... seems unclear
... chrome also returns original unscaled length of
substring
<heycam> http://mcc.id.au/temp/tl.svg
krit: Safari 22
... IE10 99.999
heycam: well then...
krit: presto has 22 as well
heycam: Batik 100.5
... think prefer unscaled
ed: yeah
krit: do you get the 100 somehow else?
heycam: is the value of textLength
krit: then I am in favor for 22
RESOLUTION: getSubstringLength does not take other text metrics into account and returns unscaled text length
<scribe> ACTION: heycam will make getSubstringLength not take other text metrics into account and returns unscaled text length in spec [recorded in http://www.w3.org/2013/07/11-svg-minutes.html#action01]
<trackbot> Created ACTION-3510 - Will make getSubstringLength not take other text metrics into account and returns unscaled text length in spec [on Cameron McCormack - due 2013-07-18].
heycam: yes
... spec does not explicitly say what happens for textlengh=0.
stop rendering? ignore attribute?
... 2 options 1) disable rendering 2) normal text length
... or third one: not disable rendering but really scale to one
dimension
krit: do we also scale stroke?
heycam: think spec is not clear but would expect stroke not scale
krit: have an example?
heycam: not right now, but can make one
Tav: discussion is silly
... it is meant to be for small changes on text length, not for
extreme values, just for small corrections
heycam: think you are right
krit: we could still specify edge cas
e
<heycam> http://mcc.id.au/temp/tl2.svg
<ed> http://jsfiddle.net/95QSD/
krit: examples show that stroke is not scaled
heycam: Tab would be in favor to
scale down to 1D
... think I agree
Tav: agree as well
RESOLUTION: Scale text to 1 dimension on textLength=0
<scribe> ACTION: heycam modify spec to Scale text to 1 dimension on textLength=0 [recorded in http://www.w3.org/2013/07/11-svg-minutes.html#action02]
<trackbot> Created ACTION-3511 - Modify spec to Scale text to 1 dimension on textLength=0 [on Cameron McCormack - due 2013-07-18].
heycam: odd behavior when
engthAdjust=spacing when text length less than widest
glyph
... in FF 10 we ended up positioning other glyphs to first
one
... think Chrome did it as well
... it ends up shifting glyphs
... but don't think it is useful behavior
... ddaly suggested setting text length to width of widest
glyph
ed: seems reasonable
heycam: all glyohs would be
aligned right
... like glyphs getting closer and closer
RESOLUTION: minumum textLength is the width of wides glyph when lengthAdjust=spacing
<scribe> ACTION: heycam to change spec to set minumum textLength to width of wides glyph whenlengthAdjust=spacing [recorded in http://www.w3.org/2013/07/11-svg-minutes.html#action03]
<trackbot> Created ACTION-3512 - Change spec to set minumum textLength to width of wides glyph whenlengthAdjust=spacing [on Cameron McCormack - due 2013-07-18].
heycam: have 2
<heycam> http://lists.w3.org/Archives/Public/www-svg/2013Jul/0012.html
heycam: first scale text in both
dimension instead just horizontal
... it often might be preferable glyphs looking ok when
scaled
Tav: not sure if that is the case
<richardschwerdtfeger> I need to answer a call. I will stay on IRC
Tav: specially on buttons when you have different text length and the font size looks different then
heycam: you are right
ed: maybe we should specify a box and let text fit the box? might not help as well
heycam: sounds complicated
Tav: think this is a 5% max
change
... mainly dependent on font
... don't see a need to change the height at all
heycam: you can get quite diffeent length from the same text but different length
Tav: you hope that the author has a good fallback
<heycam> http://mcc.id.au/2013/textLength.svg
Tav: you can find fonts that are
quite different
... at Chrome, right one looks fine
heycam: doesn't look bad
Tav: you just have an extreme example
heycam: ok
... 2nd one was making textlength adjustment only to do when
scaling down but not up
ed: sounds like a min max thing
Tav: don't make it too complicated!!!
heycam: ok
<heycam> http://lists.w3.org/Archives/Public/www-svg/2013Jul/0019.html
heycam: discussed it on
transforms
... when ever we have new enumeration values, we wouldn't
introduce new numeric constance
... since that is a bit of an antipattern in he web
... we decided to not introdcue new constant number and return
unknown value for new types
... and give an easier way to access to them
... new marker orient value has the same
... third would be unkonw instead of an constant value
... seems awkward
... Tab doesn't want new constants because this seems bad. not
having it would authors force not to use it anymore
ed: are there alternatives?
<heycam> readonly attribute SVGAnimatedEnumeration orientType;
<heycam> readonly attribute SVGAnimatedAngle orientAngle;
<heycam> attribute DOMString orient;
heycam: describes new
attributes
... that is the easier way to get the types
... I forgot that we already have an alternative
krit: means we don't want new constants?
heycam: yeah, just was thinking
the other day that it might not be that bad to add
... since there is oposition, we stay that course
ed: fine with me
<heycam> ScribeNick: heycam
krit: filterRes can be specified
by the author to reduce or increase resolution that the filter
is operating in
... usually it's done to reduce the resolution so it operates
faster
… I've never seen a real life use case
… it's unlikely the author can predict the right resolution for a particular device, and for this to be future proof
… the question is whether this does more harm than good
… and whether we should remove it from the spec
… from the implementation PoV, Presto/Blink/WebKit implement it correctly, Firefox not that much
ed: I think I've only seen it used properly for making things faster
… typically that looks pretty bad
… as you say, it's hard to predict the resolution of the target device
krit: all devices have different resolutions
… the way to calculate the filter changes over time, from software to hardware, so it make not make sense at all to do it
… it could block some implementations
ed: so you're suggesting to deprecate or remove it?
krit: I'm more in favour of removing it directly, but would understand if people want to deprecate first
…roc suggests to remove it immediately
heycam: agree, if we think it's a bad thing, remove it straight away, not say we're going to remove it
ed: which things does it affect? feColorMatrix?
krit: feDisplacementMap maybe
… and blur
… every filter primitive is affected by filter resolution, really
ed: I was thinking of kernelUnitLength
krit: we could remove it from Filters, but have a note pointing to 1.1 and say that we removed it for this and this reason
ed: wouldn't have a big impact on content, so would be fine to remove
krit: with or without a note?
Tav: I think you should put a note in
heycam: sounds fine to me as well
RESOLUTION: Remove filterRes from Filters spec, with a note pointing out why it was removed.
<scribe> ACTION: Dirk to remove filterRes. [recorded in http://www.w3.org/2013/07/11-svg-minutes.html#action04]
<trackbot> Created ACTION-3513 - Remove filterRes. [on Dirk Schulze - due 2013-07-18].
Cyril: I had an action to remove the xmlns prefix
… it wasn't so obvious. please let at my email.
<krit> krit: ScribeNick
<Cyril> http://lists.w3.org/Archives/Public/www-svg/2013Jul/0023.html
<ed> ScribeNick: krit
Cyril: we have 3 attributes
taking the xlink prefix
... one is deprected anyway
... for xml:base
... there is an issue in the draft talking about the base
element in HTML
... in HTML it allows it in the HMTL namespace but just for XML
element, for all others, the base attribute is used
... either we keep xml:base, do it HTML5 way
... or keep it in no ns
... see email for details
<Cyril> "conference is restricted at this time"
<Cyril> I'll continue on IRC
<Cyril> what do people think?
<Cyril> how should we clean the xml:base thing ?
<heycam> I think xml:base="" is not useful
<heycam> I don't think we should add a base=""
<heycam> if anything, add <base> like HTML
<Cyril> should we go the HTML way: keep xml:base and add base ?
<heycam> but even then I would avoid it unless people think it's useful :)
<Cyril> so you would prefer just having the <base> element?
<heycam> so there is a difference
<heycam> <base> applies to the entire document
<heycam> xml:base="" applies only to the subtree that it is on
<Cyril> yes, there can be only one <base> element
<heycam> I would be surprised if people are using xml:base="", to be honest
<Cyril> should we aks the HTML WG if they will keep it ?
<heycam> well
<heycam> I think maybe keeping xml:base="" behaviour, in XML documents, is needed
<heycam> since it's something the XML spec describse
<Cyril> so we would go for option d) in my email then?
<heycam> what about open e)
<heycam> *option
<heycam> leave xml:base=""
<heycam> don't introduce <base> :)
<heycam> forsake SVG-in-HTML users
<Cyril> ok
RRSAgent: make minutes
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/0// Succeeded: s/glyoh/glpoh/ FAILED: s/glyoh/glyph/ Succeeded: s/substringlength/substringlength that much/ Succeeded: s/Tav/Tab / Succeeded: s/whenlengthAdjust=spacing/when lengthAdjust=spacing/ Succeeded: s/think/thing/ Succeeded: s/to/too/ Succeeded: s/Opera/Presto/ Found ScribeNick: krit Found ScribeNick: heycam Found ScribeNick: krit Inferring Scribes: krit, heycam Scribes: krit, heycam ScribeNicks: krit, heycam WARNING: No "Present: ... " found! Possibly Present: Cyril IPcaller P10 Rich_Schwerdtfeger ScribeNick TabAtkins Tav aabb aacc aadd cabanier ed glenn heycam jaseg joined krit nikos pdr plh plinss richardschwerdtfeger stearns svg thorton trackbot xml You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0002.html Found Date: 11 Jul 2013 Guessing minutes URL: http://www.w3.org/2013/07/11-svg-minutes.html People with action items: dirk heycam modify spec WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]