Re: Re2: An Idea...

[Sergey Zhumatiy <serg asi srcc msu su>]

> I dont think applications need to know all of this ...  if they
> do, then the backend isnt doing enough work!  If you have econofats on
> for example, why should the application need to know and render any
> different?
>
> Users need a way to specify such information (via a dialogue), but why
> would an application need to know?

  I meant just you say. The 'unneded' information is needed to form
the dialogue and to save user choice for unsing it while send print request.
  May be it's better call standard function which will show dialogue to
user and then will return user's choice with all information, needed
for application (such as paper size, using color) and needed for printing,
but unneeded for application.

> >   4. May be even load of every printer (will user wait while printer
> >      will be able to print?)
>
> This is a spooling issue.  A bit beyond the scope of the application
> 'printing' api.  Still important of course!

  Thats because I said 'may be'. We can simply generate the printers
escape sequences and return it to application. And then it can send
the sequence to printer that way it want. It's not elegant, but it's
practical. Adding spooling api is not very nessesary, but very convenient.


> Well it will only support graphic printers.  So all graphics formats

                            ^^^^^^ that's RIGHT!

> are supported (well, 1 uncompressed format is, but images can
> be converted to this format using gdk-pixbuf i think).

> >   Please, tell me, what is implemented now and what's planed. Are planed
> > features, I told about?
>
> Yes planned features will include most of these, in one form or
> another.

> i.e. the application can select fonts, draw text, move the cursor,
> draw lines and polygons (filled or not), complete a page, even perform
> affine transformations (rotation, scaling, etc) and so forth.

  That's very good!
  One question: can I be sure, that my X fonts metrics and metrics of
printing fonts will be the same?


>  - some way to queue the print job.  Using lp?  lpr?  I'm not sure
>    what the plans are here ...  It would make some sense to use
>    the native print system, but well, lp sux to talk to from a
>    program.

  lp/lpr are not so good (last guqtraq confirms it), but many people
use them. I think it's needed to support lp/lpr mechanism but use
it only it user want it.

  With respect
                                                Serg.