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
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
