SVG Working Group Teleconference -- 29 Jun 2010

ED: There was discussion on the member list as well
... I had a look at this awell
... I don't think the text-text-06.svg test can pass
... according to the section
... there are other rules we should test when ligatures are formed
... when you have letter space or kerning

<ed> http://dev.w3.org/SVG/profiles/1.1F2/publish/text.html#TextLayout

ED: End of that section is the bullet list

AG: Do you think it's the bullet points that need fixing

<ed> "Ligatures only occur when a set of characters which might map to a ligature are all in the same text chunk."

ED: The above text put in an email by Alex D

<ed> "As mentioned above, ligature formation should not be enabled for the glyphs corresponding to characters within different text chunks."

ED: the last bullet point is somewhat similar
... we should remove the last one if we remove the first one
... The knock on effects of removing those bullet points could be a problem
... Do you want me to investigate what other dependencies there are with ligature forming rules
... I'll check Tiny if there's any wording
... looks the same

TB: Do you understand the purpose of the rule?

ED: I guess it depends on how the x and y position rules are suppose to work
... if it applies to the glyph or the character
... I think the x and y are based on characters and not glyphs
... so the list of coordinates in x corresponds to the first n characters
... do we have any tests for that particular thing?

AG: I made complicated one for the rotation values

ED: Do you have any ligatures in that one?

AG: No just uses a standard font

ED: Would be a bit more obvious if we use an Arabic font

TB: If you're moving characters around you should not use ligatures which is what the 1st bullet put in the last 3 is saying
... but if you read the 3rd bullet point there's an inconsistency

ED: That is sort of suggesting that we remove that one as well
... One way to move on this is to make some tests
... and see what implementations are doing

TB: I guess I'm trying to see where this would be used

ED: One problem with the test as it is
... the fact it requires SVG fonts
... because we can't test Firefox
... I think I can take an action to come up with a few new tests

<scribe> ACTION: Erik to Create some new tests that relate to the problems in ISSUE-2332 [recorded in http://www.w3.org/2010/06/29-svg-minutes.html#action02]

<trackbot> Created ACTION-2807 - Create some new tests that relate to the problems in ISSUE-2332 [on Erik Dahlström - due 2010-07-06].

ED: I would suggest waiting for this to see if there are any opinions on this
... it would be nice to see some more tests with ligature forming

ISSUE-2333?

<trackbot> ISSUE-2333 -- more BackgroundImage/enable-background issues -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2333

ED: There is some suggested wording
... I don't think it's more clear to remove that sentence
... Instead of removing the text could add to the wording to make it more clear

<ed> instead of removing "which might require the SVG user agent to allocate

<ed> buffers as large as the current viewport." we could instead make it say "which might require the SVG user agent to allocate

<ed> buffers as large as or larger than the current viewport."

ED: Depends on what we think is the right thing to do

TB: What happens if you create an image outside the viewPort and then use it?
... I know Inkscape people will create symbols outside the viewport
... then expect to use them with the use inside the viewport

ED: I think it makes sense to be able to generate things outside of the viewPort
... you have an x,y offset for enable-background=new
... so could set negative values for that
... doesn't have to be negative just outside the viewPort
... I think what the spec is trying to say is if you don't give any values then you end up with an allocation the size of the viewPort
... wait it's not exactly like that. You give it the size it needs
... in that case I agree we should remove that part of the sentence

RESOLUTION: We will remove the last part of the sentence as suggested

<scribe> ACTION: Anthony to Remove the last part of the sentence as suggested in ISSUE-2333 [recorded in http://www.w3.org/2010/06/29-svg-minutes.html#action03]

<trackbot> Created ACTION-2808 - Remove the last part of the sentence as suggested in ISSUE-2333 [on Anthony Grasso - due 2010-07-06].

ISSUE-2334?

<trackbot> ISSUE-2334 -- filter primitive subregion and feGaussianBlur, feTile and infinite filter input images -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2334

ED: We've discussed this before
... it was one of the issues raised by ROC
... as Opera implemented it's a hard clipping region
... you might not get the edges as you expect, things might extend outside the filter primitive subregion
... I think he wants to get rid of the clipping part so graphics will look the way they should

AG: I've noticed the same thing with blur filters

ED: I dunno if we change the meaning of subregion is that useful
... to say that the width and height are ignored
... as in analysis the filter change to see what areas are affected

AG: Wouldn't you want to keep the max width and height in the filter chain

ED: You may want to do the clip though

TB: Are there any use cases for this?

ED: I have used the subregions for cases where the filters are very expensive to run
... essentially for us this is a rectangular clipping region
... this is a change I would be more willing to make in the filters module
... because it can be useful for very expensive filters

TB: Let's take the case of the blur
... you have two choices
... with the area defined
... you use only the stuff within the region to calculate the blur
... or that it has a region of interest
... if you're restricting the output area then you're not going to have artefacts along the edge
... if you're only concerned about the output you wont have any discontinuity
... that's what I think this is getting at

<ed> http://www.w3.org/TR/SVG11/filters.html#FilterPrimitiveSubRegion

ED: In the cases I've seen, it's not just the subregions clipping things

<scribe> ACTION: Erik to Investigate ISSUE-2334 and report back [recorded in http://www.w3.org/2010/06/29-svg-minutes.html#action04]

<trackbot> Created ACTION-2809 - Investigate ISSUE-2334 and report back [on Erik Dahlström - due 2010-07-06].

ED: Potentially it's a bigger change than I feel comfortable doing for this spec

TB: I think it's about defining it better

- DRAFT -

SVG Working Group Teleconference

29 Jun 2010

Attendees

Contents

Last Call Comments

Summary of Action Items

Scribe.perl diagnostic output