Re: Customer requirement #1: Decrease font size

On 02/24/2013 12:24 AM, Liam R E Quin wrote:
> 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?
>
Yes, I believe so. We're still not talking about telling implementations 
*how* to do things; we're expanding the scope of how to tell them *what* 
to do.

Typically you'd end up with a good language-neutral "abstract" API. Use 
case work and requirements definitions, such as we've started here, 
leads to this abstract API (pseudocode for all we care). It's the same 
use case/requirements work for either doing this and/or designing new FO 
XML.

You'd typically then "implement" a few language-specific version of the 
API for prominent languages, see how it hangs together.

I think it would be productive to do this, yes. I believe that until we 
prescribe this kind of extra standardized interface to FO formatters we 
can't assume it would be a waste of time. I am partially a user in this 
regard too, I do some work with ECM systems and DITA publishing, and I'd 
be happier sometimes if I had programmatic control for unexpected 
situations when rendering using an XSL FO engine.
>> The API *is* the formatter, just a different interface to it.
> No, the formatter is he formatter. An API is an interface to something.
I'm a hard-core long-time software developer, different mindset. It 
leaks out. :-)

The "something" here is the formatter. To me this kind of API *is* the 
"something", as far as a given client is concerned.
> 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.
I'm cool with all of that, I think they are solid choices also. I 
probably wouldn't have started working with FOP back in James Tauber 
days and after if I thought those tenets were bad.

I am quite confident that I'm making no suggestions here that disrupt 
these principles. As for FO formatter APIs that exist now, like I said 
above, this kind of API we are talking about here in no wise prescribes 
to them how they need to make things happen; we are only providing 
another mechanism for telling them what to do. If we then provided ways 
in this programming API to get events and geometry information etc, and 
act on it, that's no different than modifying the FO to achieve the same 
ends, for any given scenario. In fact the guts of a formatter should  
never know _how_ they were instructed.
> 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?
>
>
>

I don't myself see JavaScript as an API for a web browser. The real API 
is the browser state and events (e.g. document, DOM events, window 
events, AJAX-type events etc) that you can conceptually and practically 
access and make use of. That JavaScript is the predominant browser 
scripting language doesn't mean that it's the only one, nor that people 
thought it had to be. But that's all it is, just a  browser scripting 
language.

Returning to our situation most of the heavy lifting has to do with 
deciding exactly the kind of thing you mention for callbacks for 
font-loading events, except for FO. As we discuss formatting feedback 
(which is actually the combination of the information being returned by 
the formatter [whether internal or exposed programmatically] *and* the 
action taken upon that information to influence the formatter), it's 
immaterial _conceptually_ as to whether we modify FO to handle that, or 
do it programmatically. Properly designed the core formatting engine 
doesn't care how it's been instructed.

 From a *practical* standpoint I think there are advantages in 
considering how a given formatting feedback problem could be handled 
with instructions not just in pure FO but also programmatically. Also 
from a practical user standpoint this is the kind of thing that appeals 
to me...more options to control my work.

Arved

Received on Sunday, 24 February 2013 12:06:36 UTC