minutes, Thursday 19 May 2011 SVG WG telcon

Minutes from today’s telcon below.

Present: Cameron, Erik, Vincent, Rik, Tav, Glenn Adams
Chair: Cameron
Scribe: Vincent

Topic: Proposed July F2F date

http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/0084.html
heycam: Erik sent out a proposal.
erik: I sent an email to Patrick Dengler and he seemed positive about the date.
erik: Microsoft may be able to host.
heycam: Is Microsoft already hosting around SVG Open?
vhardy: Adobe is looking at possibly hosting in July. No answer yet.
cabanier: there are also Google offices in Seatle.
heycam: when Doug is back, he'll set up a survey to confirm this is acceptable for everyone.
ed: I wanted to confirm that it is fine for everyone with proper confirmation.
heycam: ok.
heycam: we should soon start talking about the meeting agenda item.
http://www.w3.org/Graphics/SVG/WG/wiki/Seattle_2011
heycam: people can add agenda items to this page.
heycam: I think it would be good to concentrate on animation again.
cabanier: I agree.

Topic: recent discussions about text issues.
heycam: Glenn said he would call in.
heycam: I do not have much more to say than what is in the thread. I am writing a proposal to define precisely text layout precisely when you have text-anchor, bidi and glyph positioning.
heycam: there is a quite a lot of interoperability problems.
heycam: this is an incentive to clear up the specification.
vhardy: is that for SVG 1.1 3rd edition or SVG 2.0?
heycam: SVG 2.0.
heycam: I guess that the major thing I was proposing is to change how the text chunking work. And not create a new text chunk in the absolute positioning stage.
heycam: the remaining issue is to make sure that we satisfy use cases, proper text anchoring and combination of features.
vhardy: are you going to add new test cases?
heycam: yes, that is a good idea.
heycam: the test cases in the test suite do not test all these combinations.
heycam: there are only two tests in the test suite on text-path.
heycam: there is nothing that says what happens to text that goes beyond the text path.
heycam: I will add more test for text-path as well.
heycam: tbah, you brought up a similar issue recently?
tbah: yes, this is something I brought up during last call.
hewcam: yes, we decided to not change the spec.
tbah: I created a new test.
http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/ligature-breaking.svg
tbah: I looked at what the browsers currently do and they do not implement ligatures today.
vhardy: with our without SVG fonts?
tbah: without.
ed: for Opera, there is a difference between SVG fonts and non-SVG fonts. We do form ligatures with SVG fonts but not otherwise.
heycam: one of the broader questions is whether SVG should have a mechanism to index glyphs instead of characters?
cabanier: like PDF?
heycam: I think so, but I am not exactly sure what PDF does.
cabanier: like referncing the ligature glyph directly?
heycam: yes.
heycam: I one of the emails to Glenn, I talked about a glyph reference, outside of any particular character.
heycam: you cannot always reference a glyph with a unicode character.
heycam: one other question I had was whether the use case is assuming we can use the text layout engine to know how characters map to glyph. Or we cannot get how characters map to glyph from the implementation?
heycam: I think the answer was to decide whether we need to do glyph references or not.
cabanier: then you would need to specify an encoding. 
tbah: what do browsers do now?
cabanier: they rely on the OS text engine.
vhardy: yes, I think that most browsers use the OS text engine except for some simple cases.
heycam: in Firefox, the SVG text layout is done separately from the CSS text layout.
heycam: in turn, that CSS text layout uses platform support.
heycam: regarding the selection of particular glyphs. You can easily reference a glyph by name from an <algGlyph> or a <glyphRef>
heycam: there are some attributes that are losely defined that would let you reference glyphs from fonts in a unified way, not using the unicode character.
http://www.w3.org/TR/SVG/text.html#AltGlyphElement
heycam: look at the format and glyphRef attributes.
heycam: if the format was an OpenType font, there should be a way to reference the glyph.
vhardy: so we don't know what the glyphRef attribute string value would mean for non-SVG Font formats.
vhardy: should we coordinate with the WOFF WG on this?
heycam: yes, we should.
heycam: if Chris joins the call next week, we can raise it with him.
tbah: we should think about it for 2 different use cases? One is for artistic uses of the font. The second is large amounts of text.
tbah: I do not see browsers want to implement a lot of extra stuff.
heycam: I think the use case for selecting particular glyph and doing glyph positioning is the same.
heycam: when you have done a fancy layout, you want to guarantee the glyphs and their positioning.
tbah: if you have a complex script, you probably just want to rely on the experts who have written the text engines.
tbah: I have a hard time seeing that someone will take a lot of efforts to get a few characters correct.
heycam: I assume this is coming when people use tools to create content.
glenn: One of the reasons for SVG in the early days was to have an XML representation for PostScript/PDF like functionality. One of the requirements was to have glyph positioning and glyph selection. SVG should do that as a minimum. The next level up, is to do the character to glyph mapping. My concern is that there is not clear distinction between glyphs and text. The second requirement is formatting characters.
heycam: placing characters works for simple latin text situations (like ligatures), but it does not work for other, more complex situations (like more complex shaping).
glenn: my perspective is that I need to be able to do the character to glyph mapping in the application and then output glyphs and their positions. I need to be able to refer to glyph identifiers and position the glyphs. Then, the SVG engine should not do further mapping.
cabanier: it seems that all you need is glyph ids.
glenn: PDF requires that you use actual character codes. But the codes I use are not unicode characters. 
glenn: I had to create a different mapping to access the glyphs that I need.
glenn: the glyphRef element is SVG should provide the functionality I need.
glenn: I need to do more experiments to validate that all the functionality I need is there (spec. and implementation).
glenn: my only conceptual concern is that I still need to use a <text> or <tspan>. I believe the semantic of these elements makes it possible for the UA to do further character to glyph mapping. This may conflict with the authoring we want were we need to freeze the character mapping.
glenn: there are issues with text selection as well.
glenn: we need to be able to associate the original character and the glyphs that it eventually mapped to.
cabanier: that would be the n:m unicode mapping that PDF has.
glenn: I sent an example with pseudo-code.
glenn: with each output glyph, I keep a list of character ranges from the original character stream. For example, a glyph may have originated from multiple, non-contiguous intervals in the character stream. Multiple glyphs may refer to the same character or intersecting intervals on the original character stream. 
glenn: if you have four characters in the original stream, index 1 and 2 may generate 1 glyph. 0 and 1 may generate another glyph. These are intersecting intervals. There is not a unique mapping from a glyph to the original character.
glenn: the mapping process that I am using is what is prescribed by the Open Type's GSub and GPos tables. There is a similar system in the Apple GX fonts, using different tables. This is used in Arabic and Hindic and some south east asia.
tbah: so you are taking care of the mapping in the application itself?
glenn: yes.
glenn: I perform the character to glyph mapping process.
glenn: then I generate PDF or SVG.
tbah: the problem with SVG is how people can select text: they may not get the original text that came from the font.
tbah: so do we need a new structure in SVG?
glenn: if you introduce character to glyph mapping, this would create a new issue.
cabanier: PDF has a glyph to unicode table.
cabanier: when you copy or find in a PDF document, that table is used.
glenn: PDF lets you annotate a glyph so that you can deal with selection and search.
glenn: I wanted to make people aware of what I was doing, especially in the context of SVG 2.0. I could assist in this process. My interest comes from my work in FOP.
tbah: what does HTML do for this?
glenn: User agents make use of the platform text layout engine. On Linux, there are some open source implementation of this process. It is on a per user agent bases, and different browsers accomodate the differences between platforms. 
for PDF, the reference manual describes how this is done, see: 5.9.1 Mapping Character Codes to Unicode Values
vhardy: what is missing from the current SVG 1.1 spec.?
glenn: I have not implemented the SVG output yet. I am currently speculating based on my reading of the spec. I plan to go through that process in the next few months. I will have more feedback then. I am commenting on my initial reading of the spec.
glenn: I believe the glyphref should address my need. I believe there will be issues with selections, copy and search.
glenn: this is something I have to face with other formats. I am also concerned about the semantic of the <text> element which assumes the UA will do the character to glyph mapping.
vhardy: there is also the <altGlyph> element that may help.
glenn: yes, let's hope this will do the trick.
glenn: but I suspect there are issues that have not yet been addressed.
glenn: I'll experiment and report back
cameron: we would be happy to have that information
glenn: also per glyph scaling, colouring, shadowing, etc. I'm not sure if I could output a line of a text on a bezier curve and position the glyphs and scale them and perform other transformations to the glyphs specifically
glenn: I can do that if I represent them with paths, but drawing a text on a non horizontal/vertical line might be problematic
glenn: it's not on my list of things to do right now but I thought I'd mention taht
cameron: there is textPath, which does positioning/rotation of glyphs along a path, but it doesn't do any non-affine transforms
glenn: the use case I'm thinking of is applying graphical transformations to individual glyphs
cabanier: I think we can already do this. instead of doing individual glyph positions you can do textPath to place the text on a path.
cameron: I will send out my proposal for text-anchor/bidi/positioning to www-svg later today

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 19 May 2011 21:20:43 UTC