Print Card is broken in Linux because of resolution dependence

[Richard Gaskin]

Peter Alcibiades wrote:

> Changing the look and feel doesn't seem to do anything much.  The colors
> change fractionally, but with the size of the IDE what it is, its barely
> noticeable.  Its sort of a very limited theme control apparently.  It seems
> to affect highlight colors, but that's about it.

Did you try printing as well?  I wouldn't expect using the Motif 
lookAndFeel to allow Rev to display with resolution-independence; 
instead, the goal of that exercise was to see if it would bypass Rev's 
GTK support sufficiently to allow more consistent rendering to the print 
buffer.


> Thanks for the dictionary link.  Two hours later, thanks to webttrack, we
> have a copy of the dictionary that will display locally in a browser window.
> That will certainly help.

Nice.  Glad that was useful.

> Can it be drivers?  Its hard to see how.  It would have to be the identical
> problem with the drivers in cups-pdf, in the ppd for the Kyocera, and in the
> drivers for a Konica Minolta hung off a Jetdirect print server.  Can't be,
> can it?

Not likely, but it's hard to say with certainty until you try.

With Windows I had similar complaints to Scott Raney back when he owned 
MetaCard:

    Me:    This only happens with MetaCard!  Never with anything else!

    Raney: Just the same, please check to see if you have the latest
           print driver.

    Me:    What a waste of time!  This is stupid! How can it be the print
           driver if everything else is printing fine?

    Raney:  MetaCard is very good at exposing bugs in print drivers.  I
            can't speak for how others write their code that uses them.
            Just check the driver and let me know how it works out.

    ::: I went away and found that there was a new version of the driver.
    ::: Later on, I wrote back to him:

    Me:     Okay, it works now.  The problem went away.  Why?

    Raney:  I don't know because I don't have access to other people's
            source.  I just know that what we do is on spec and
            generally works as long as the driver itself has no bugs.
            But most drivers have bugs, and most printer companies issue
            regular updates to address them.

In my experience, updating drivers on Windows has resolved almost all of 
the printing issues I've ever had, with the remainder being "user 
errors" in which I forgot to set the formatForPrinting to true and 
things like that.

Whether any of that applies to Linux is hard to say, but it just seems a 
good diagnostic move to verify that the driver version is the most 
recent available.  All software always has bugs, and that means not only 
Rev but drivers too.  The Linux world has a bit of a reputation for 
home-grown drivers of greatly varying quality.

But beyond the driver itself, the problem may lie with how Rev is 
interfacing with it.  But again, verifying that the driver is the most 
recent available will help narrow down the source of the issue.



  It would also have to be some kind of defect in all these drivers
> that does not affect either graphics editors, text editors or OpenOffice.
> How can it be that OpenOffice, regardless of screen resolution or
> distribution its running on, always prints a document in a given font at the
> same size on paper, if there is some problem with the print dirvers?
> Surely, for properly written applications, print rendering is independent of
> screen rendering?

Not entirely.  After all, why write two routines to do the same thing? 
While the specific API calls under the hood will be different, I would 
imagine that much of the internal routines that write to the display 
buffer are also used to write to the print buffer.  A good many other 
programs use a similar approach to deliver WYSIWYG printing.


> I'll have a look at the revPrintField code.  My health will not allow any
> very intense effort on it, though.  Is there really no-one in Edinburgh who
> can look at this stuff?

"Can"?  Probably.  "Would like to"?  Almost certainly.

But "can afford to take time away from so many items on the front burner 
while so few people are using Linux?"  Not likely.

This is a common issue in the Linux community at this early stage toward 
their inevitable domination of the computing world.   Within five to ten 
years it'll be foolish not to give Linux top priority because it'll be 
on par with Mac OS with each having at least 35% of the market and 
Windows will have dropped below them, but the Linux world is still 
learning about evangelism, so the process will take some time. ;)

In the meantime a good many apps aren't available on Linux at all just 
yet, and many of those that are - like Rev - aren't as feature-complete 
as their Mac and Windows counterparts.

We see this with printer manufacturers as well, which is why so many 
printer drivers in the Linux world are home-grown - the manufacturer 
simply hasn't delivered one themselves, so the community steps in and 
makes it happen.

And so it is with RevPrintField:  it need not be yourself, but we've had 
a number of FOSS advocates on this list and I'd like to believe that a 
good many of them would jump on this opportunity to demonstrate the 
value of being able to enhance code that's been made available to them.


> Anyway, last night I started on plan B, rewriting the print parts to remove
> all use of Rev printing, and ran into the next thing, which is that when you
> do cut and paste in the IDE editor, it freezes.  Or rather, it seems to go
> into a loop, the cursor sits there flickering and is locked.  Then when you
> close the editor, it crashes the whole IDE, so you lose work since the last
> save.

Feel free to drop a report into the RQCC on that, but unfortunately 
that's not something I can advise on.  I wrote my own script editor 
years ago (I had line numbers half a decade before Rev did <g>), and 
have been happily using it and enhancing it ever since, so I can't 
remember the last time I've even seen Rev's script editor (though when I 
did I recall it regularly submarining under Rev's tool palette, which 
seemed odd given how the Rev IDE narrows the windowBoundingRect; oh 
well, another mystery for another day).

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv