Good sleuthing. I would suggest you copy the bulk of that post to an
RQCC bug report so those useful details aren't lost over time.
At the current time none of the engines Rev makes are
resolution-independent, even as all of the platforms they run on, from
Vista to Snow Leopard and even iPhone, are all resolution-independent.
I believe Kevin has stated publicly that an initiative to migrate the
rendering subsystem to a resolution-independent model is in the works,
but I do not have a timeline for such enhancements.
It would seem reasonable that they would tackle this across all
platforms at the same time, so I would not expect such a radical
overhaul to be done sooner for Linux only.
I agree that this is unfortunate because the problem is more pronounced
in Gnome than on other platforms, but not for reasons of Rev's making as
I noted earlier:
<http://lists.runrev.com/pipermail/use-revolution/2010-March/135822.html>
<http://lists.runrev.com/pipermail/use-revolution/2010-March/135800.html>
Based on the widespread complaints of Gnome's rendering scheme and its
uncommonly large controls even on displays running at the same
resolution as other OSes, it seems the Gnome team has some work to do.
Given that my earlier testing showed striking similarities between Rev's
text rendering and Firefox's (both using a rendering scheme that assumes
a fixed resolution, as noted in some of the Gnome bug report
discussions), it may be worth repeating at least a few of your excellent
tests with Firefox to see if they compensate for the difference.
The upside for us Rev folk is that while it's a bit of work to change
the Rev IDE, this issue should be completely compensatable in our own
code with relative ease by just setting the size of things being printed
to larger dimensions in your offscreen printing stack.
One remaining challenge would be to update RevPrintField also, but one
of the distinctions of the FOSS community is a willingness to dive into
source to make changes as needed, and the source for RevPrintField is
openly available. If one of the FOSS advocates on this list were to
refine that code to work better on Linux I see no reason why a robust
well-tested revision wouldn't be welcome by RunRev for inclusion in
their IDE.
--
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
-----------------------------------------------------------
Peter Alcibiades wrote:
Print Card is broken in Linux. The problem is a general one with
resolution dependence, and it is the same thing that makes the IDE
unreadable on a larger screen. Here is what showed it.
I used a 19 inch screen set to the normal resolution, and printed a card
to cups-pd. I then also printed to a kyocera physical printer. I did
this using the message box, changing the printerName between PDF and
kyocera. Then I printed the pdf file generated by cups-pdf to the
kyocera using kpdf.
Both prints came out on paper correctly sized, and identical.
I then changed the screen resolution to 800 x 600, and repeated the
experiment. They both came out enlarged, so that the card did not fit
on the page, but they were identical.
It follows that cups-pdf and a real printer work identically in Rev.
But print card works differently on both with the identical parameters
if the resolution of the monitor changes.
Conclusion: in Linux, if you change screen res, the identical scripts
will no longer print cards in the same way. This is because the print
card command is in some way tied to the resolution of the screen being
used. The problem is nothing to do with Linux printing, print drivers,
anything like that, its specific to Rev and how Rev has implemented the
print card function. Its not the fault of Linux either, since no other
app has this problem. Just as no other app has the Linux font problem.
Since revPrintField is not properly usable in Linux for different
reasons, this means that the current version of Rev for Linux does not
support printing.
The resolution dependence thing is also a real problem in regard to the
IDE. On the 19 inch screen everything is fine, the dictionary is
readable, the icons are about right. On my 22 inch screen at home, you
need to use a magnifying glass to be able to read the dictionary which
looks like its 4 point. So on my machine at home, basically I have
unusable printing and an unreadable IDE. On the application site, the
IDE is usable, but printing isn't.
You see the problem this creates, when coupled with the lack of support
for multiple desktops. You want readable fonts in the IDE, fine, you
have all your different windows all overlapping one behind the other.
You get a big screen, they don't overlap anymore, but now they are
unreadable.
Plan B is going to have to be used for printing. I had hoped to be able
to hack it with cups-pdf, but from the above, this obviously does
nothing to solve the problem. Plan B involves hacking around with awk
after putting all the text into a text file to generate some kind of
readable report. What a waste of time!
So, question is, what is the plan? Is the plan to continue shipping
Linux versions with no usable printing? Or is it to fix it, and if so
by when?
_______________________________________________
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
