Minutes 20 August 2002

SVG Working Group Teleconference
Thu 20 August 2002
--

Attendees:

OA: Ola Andersson (ZoomON AB)
PA: Phil Armstrong (Corel)
BB: Benoit Bezaire (Corel)
CC: Charilaos Christopoulos (Ericsson)
MC: Mattias Larsson Carlander (Ericsson)
TD: Thomas DeWeese (Eastman Kodak)
JF: Jon Ferraiolo (Adobe)
JU: Jun Fujisawa (Canon)
RG: Rick Graham (Bitflash)
UH: Ueda Hirotaka (Sharp)
DJ: Dean Jackson (CSIRO/W3C)
LK: Lee Klosterman (HP)
TK: Thierry Kormann (ILOG)
RY: Rick Yardumian (Canon)

Scribe: 
Rick Yardumian

Regrets:
MB: Mike Bultrowicz (Savage Software)
AD: Alex Danilo (Canon)
TH: Takanari Hayama (KDDI)
LH: Lofton Henderson (OASIS)
CJ: Cristophe Jolif (ILOG)
CL: Chris Lilley (W3C)
AQ: Antoine Quint (ILOG - Invited Expert)
CY: Charles Ying (Openwave)

Absent:
TC: Tolga Capin (Nokia)
DF: Darryl Fuller (Schemasoft)
VH: Vincent Hardy (Sun)
AK: Arei Kobayashi (KDDI)
PM: Philip Mansfield (Schemasoft)
LM: Luc Minnebo (AGFA)
SO: Shuichiro ONO (Sharp)
TS: Takeshi Sagara (KDDI)

--
MC: New person from Ericsson, Charilaos Christopoulos. He will attend the Rochester trip in my place.

Rochester face to face:
TD: I've sent info on hotel. It's a nice hotel and I recommend you stay there but you can stay elsewhere if you want. Social event is Tuesday night. I'm organizing a trip to the finger lakes. There's wine growing there so if there's people interested, I can arrange a trip on the Sunday before the meeting for wine tasting. We'll have two cars. Send email if you're interested. We'll leave late in the morning.
DJ: Take roll call of people attending the Rochester meeting.
  OA: Ola Andersson (ZoomON AB)Not sure
  PA: Phil Armstrong (Corel) Yes
  BB: Benoit Bezaire (Corel) Yes
  CC: Charilaos Christopoulos (Ericsson) Yes
  MC: Mattias Larsson Carlander (Ericsson)No
  TD: Thomas DeWeese (Eastman Kodak) Yes
  JF: Jon Ferraiolo (Adobe) Probably
  JU: Jun Fujisawa (Canon) [wasn't on call at roll call time]
  RG: Rick Graham (Bitflash)may have to call in
  UH: Ueda Hirotaka (Sharp)Yes
  DJ: Dean Jackson (CSIRO/W3C)Yes
  LK: Lee Klosterman (HP)Probably
  TK: Thierry Kormann (ILOG)Yes (plus another guy from ILOG)
  RY: Rick Yardumian (Canon)Yes

TD: Please RSVP if you are going to the meeting.

Test Suite:
RG: I sent an email.
DJ: I'm looking at your web page. It's got all kinds of colors. Can you give a quick summary of what needs to be done?
RG: Most of the remaining work is "piddly". Chris hasn't turned his tests in. I assigned Antoine's to someone else. There's a few notes, 4 or 5, that we should fix up.
DJ: Chris said a day before his vacation that he'd get the tests done.
RG: If we could spend some time going through these, I would accept assistance in getting this done.
DJ: Lets go through the email [subject: test suite status, 8/20/2002]
RG: A couple in here are flagged for Olga, <animate-elem-09-b-a>. <animate-elem-11> is probably done now. Phil did <filters-example-01-b>. Dean is fixing <animate-elem-09-b-a> per Rick's email. Antione's tests are done. Let's leave <filters-example-01-b> as is since it's just a aesthetic problem. 
DJ: Not clear what's needed for <linking-a-01-b-a>
TD: Chris Lilley wanted these fixes but I'm not sure that's appropriate. About the '#', something about you can only reference complete documents in Tiny.
RG: This is kind of muddy in my mind now. Does anyone know what this is about (Mattias)?
MC: I don't know.
RG: Lets leave it as basic and move on.
DJ: <render-elems...>
RG: These should use SVG fonts.
TD: The t element, not the d.
DJ: You could use global replace.
JF: You could also use XSLT.
TD: Batik is pretty simple.
RG: I'll get Vlad to look at it.
TD: The real issue is what SVG font are we using.
RG: Does it matter?
TD: It matters what source the font comes from.
DJ: You can use Microsoft web fonts. You can't get them anymore but most people already have them.
DJ: You're not at work today Rick G.?
RG: Right, I'm not well and may be off tomorrow too.
DJ: <script-handle...>
TD: If I recall correctly, the description still refers to them as one file.
RG: These tests should use animation rather than scripting with an explanation.
TD: So the test name is script-handle but we can't use scripting?
RG: Valid comment.
TD: I understand that Chris wanted this for Tiny but he wants two tests.
RG: We already have lots of animation tests so why bother?
DJ: I say don't do anything with this one. 
RG: script-handle tests should be basic not tiny.
RG: <struct-cond-02-t>
DJ: Trashed, why?
RG: Vincent scripted it and broke something. Chris said it needed to be redone.
TD: I think the multibyte stuff got messed up too.
RG: Yes.
RG: <struct-dom-01-t>
TD: It's using the svg 1.0 monolithic fixed DTD. That DTD needs to be part of the distribution but it's been lost. I recall that something was added.
DJ: I can't see anything in the operator script that needs a DTD. Lets change it to normal and ask Chris why the DTD is needed.
RG: What do you get when you click on it?
DJ: I don't believe any implementation can pass this test using Ecmascript.
RG: Batik does not pass it.
DJ: The comment is we're testing the DOM and I implemented a Javascript that did it.
RG: You're saying you wrote a special program to pass this test?
DJ: Yes. Has Batik done baseVal? 
TD: Yes.
DJ: Then Batik could pass in the same way. Batik might be able to pass using Ecmascript.
TD: Maybe. Part of the problem is that they are assigning to a baseVal which may be read-only.
TK: There are errors like get parentNode and others that need to be fixed.
RG: Are you saying there are errors in the scripts that work?
TK: You're not required to support getParentNode. I think we should fix this. I'll send email to the group about where all the errors are.
TD: I was only suggesting that was the case, no one knew for sure.
TK: If it's readonly, that does not mean you can't call a method to change the baseVal. It means the pointer on the object cannot be changed.
RG: That means these lines are probably incorrect.
TD: What TK is saying is that this may be correct since he's changing the enclosed value not the pointer.
DJ: TK will send out a list of possible script changes. We'll see if Batik passes.
TK: So you can change the value use the setValue method.
TD: The stuff in <struct-dom-02-t-a> is the same as <struct-dom-01-t>. TD calls out a line number.
TK: That's correct.
RG: The correction is that the script is broken. If that's not broken something else is.
TD: It's possible there's a bug in Batik.
RG: <struct-dom-02...> works in Adobe.
DJ: <text-align...>
TK: I remember this one. Right now we have to use 0 deg. After the fix we won't need the deg units.
DJ: So the option is to change all the 0 to 0 deg where needed. We've agreed that Tiny does have text anchor.
RG: Yes, we agreed that Tiny should have text anchor and throw away multiple x and ys.
DJ: Yes, we took a roll call and that's what we decided.
DJ: <text-deco...>
TD: This list in your email is a small fraction of the list on your (RG's) web page.
RG: Most of the stuff on the web page is resolved. Everything that's green and brown are fine. There are two other things. Did we do anything for linking targets?
DJ: I don't want to hold up the test suite for that. 
RG: Right. It doesn't hold up the test suite but I can't generate the test framework. It would be nice to get it done so the framework has all the proper links to help testers.
DJ: That would be cool but we need to get the test suite out ASAP. We'll do that later. We're so far behind exiting CR that we have to get the test suite out.
MC: Did you (RG) say you'll fix the last two tests in the list? <text-...>
DJ: Can you (RG) get this done in the next couple of days?
RG: It depends on how I feel.
MC: I could fix them.
DJ: Great, MC will fix <text-spacing-01-t>, <text-text-01-t> and <text-text-02-b>.
DJ: <text-deco-01-b> problem is there's too much in this test and we need to do additional tests. Let's hold off on this for now. 
RG: If we can get all of these things resolved, we can have a framework.
DJ: Can they be checked into CVS?
RG: Absolutely. If we can get them done by Thursday we'll be OK.
DJ: Is there anything else?
RG: No. (RG signs off)

ACTION 129: 
DJ: JF thinks one thing, TD disagrees. Having read the email thread, ignoring most of the spec discussion and looking at JF's use cases, I like the results of the examples.
TD: My problem is that there are two potential clips. If we do what JF's suggesting the two must always be the same and I don't agree with this. There's the clip before which comes under the zoom control and the clip after which comes under document control. 
JF: So you're saying if you zoom the html you want it to re-layout?
TD: I want the map to become bigger rather than staying at the same size.
JF: If you zoom and zoom and zoom the SVG would take up the entire page.
TD: No, the html would also get bigger and you'd have scroll bars to handle this. Why do you say the html disappears?
JF: If you're saying the SVG gets bigger, at some point there would be no html left.
TD: No, the HTML would reflow around it.
DJ: Jon is saying that if you click on the SVG map, the HTML user agent has already negotiated the size for the SVG area and zooming the SVG map should not change that negotiated SVG area.
TD: When a zoom occurs, the html agent has a bunch of options, it can keep the SVG are the same or the SVG area can grow in the HTML document.
JF: That's not how HTML works.
TD: It works for tables.
JF: The object tag is the standard way of including SVG. You can also put SVG markup directly in the HTML. In both cases, the CSS positioning properties determine how big that SVG blob is. The only values you have for width and height are absolute values, relative values (dependent on the previous SVG content) or percentage. There is no value for the width and the height values based on things that are happening inside that box.
TD: You're describing the width and height on SVG?
JF: No.
TD: On a table you don't have to provide width and height and the table can get larger.
DJ: But you've added content which is different than zooming. It used to be the case that you could zoom a particular image.
TK: You can also just grow the font size and all the images will stay the same.
DJ: The issue is that the width and height negotiated has not changed.
TD: The reason the images don't change is that the font size was changed and that doesn't affect the images.
JF: The key thing about html is that it follows the CSS rules which has a chapter on text, tables, and nested boxes. One of the boxes could contain a SVG image.
TD: It's not activity within the box.
JF: It is acitivity within the box. 
DJ: I agree with JF. Did you ever consider in Batik that the window should be made twice as big?
TD: I think that's good behavior.
[JU just joined]
TD: I feel that those decisions are the hosting agents choice. If we say that the clip happens outside of the zoom/pan, the user agent doesn't have control. My feeling is that after the zoom/pan, I'm going to clip. 
DJ: If you pan in the SVG, do I have to reposition? That seems to be a similar use case.
TD: If the user agent decided to put scroll bars on, you would.
JF: So what's the difference in Batik?
TD: If you pan you can't the stuff outside of the viewBox. Everywhere else we use viewBox, it behaves this way. The clip is done in the element user coordinate system. Now we're saying the clip is done in the parent's coordinate system.
JF: The way you're proposing produces some absurd output. Say you have a square picture and you say prefer aspect ratio. If you have a skinny window, parts of the picture are are going to be sliced off the left and right. Even if you pan you won't be able to see the missing pieces.
TD: Yes if you say overflow invisible.
JF: There is no opportunity for the HTML to use it's own clip.
TD: It's a mistake.
JF: The point in my email is, that it is a design goal to allow SVG in HTML whith a single property that serves as the clipping for the parent and the child.
TD: You should have two properties or you have to eliminate having a zoom between the SVG and HTML.
JF: We did all that and made decisions.
TK: There is a test that demonstrates this. <coords-units-be-01> (spelling?)
If you zoom out you won't see the rectangle, if you use Batik you will see it. There is a pointer to the spec chapter 7.1
JF: That's a bug in Adobe.
TK: No it's supposed to be that way.
DJ: Let's give this a week break and rediscuss it when Chris is back. Background fill depends on this. It's not urgent to solve this before we put out a draft.
TD: Also can you define a background that doesn't scroll and zoom.
TK: You will see the background everywhere even if you zoom out and scroll.
DJ: Let's leave this until later. I encourage everyone to check the draft I put up today. We'll talk about it on Thursday.

*** END ***

Received on Tuesday, 20 August 2002 11:19:28 UTC