- From: Liam R E Quin <liam@w3.org>
- Date: Sat, 23 Feb 2013 23:24:05 -0500
- To: Arved Sandstrom <asandstrom2@eastlink.ca>
- Cc: public-ppl@w3.org
On Sat, 2013-02-23 at 20:50 -0400, Arved Sandstrom wrote: > [...] > If the formatter exposed such an API, it could be programmatically > controlled by a client app, which would receive events that it has > registered for, and be able to act on them. Is that something that's productive to standardise between implementations? In Java, C#, C, C++, python? > The API *is* the formatter, just a different interface to it. No, the formatter is he formatter. An API is an interface to something. The reason we have a declarative language is that you can use it with lots of different back-end formatters, not all of which have compatible APIs or ways of looking at the world. I think this was probably a good choice, with vendor-specific enhancements also making a lot of sense. If you consider JavaScript to be (in part) an API for a Web browser, you can see that there's hundreds, maybe thousands of person-years of effort gone into developing the specs, and yet Web browsers are much less sophisticated formatters than print engines, and that's only in one programming language. Right now CSS+WebApps have been thinking about the callbacks for asynchronous font loading events, but there's not yet any API to get at the OpenType GSUB tables for glyph substitution, you can't move control points around or add glyphs on the fly (it'll come). Where do you stop? -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Received on Sunday, 24 February 2013 04:24:09 UTC