On 28 Feb 2008, at 15:51, John-Mark Bell wrote:
On Thu, 28 Feb 2008 10:57:32 GMT, Dr Peter Young
<[EMAIL PROTECTED]>
wrote:
Is there any prospect of this PostScript problem being sorted out?
Not be me at least -- it was bad enough fixing PDriverDP without
direct
access to either a printer or, perhaps more usefully, a RISC OS
machine. I
don't have time to wade through the thousands of pages of PostScript
language specification to work out what's required. This effort
would be
most certainly wasted, anyway, as people who are already experts in
dealing
with PostScript are working on improving PostScript printing.
There might be something you can do in NetSurf to get PostScript
printing
working - Kevin Bracey had a couple of suggestions when I was adding
Unicode support to ZapRedraw:
Yes, it's mapping the stuff to PostScript fonts that's the problem.
Lots of
work from a PostScript guru needed there. It might require
PostScript 3 to
make it work.
<snip>
I think we're talking at cross-purposes here. You said UCS support
in VDU
mode, so I assumed you meant using the system font, which can be
achieved
using the Service_International call to redefine character <n> as UCS
character <u>.
Browse could do this - it sort of used characters 80-FF of the
system font
as a cache of recently needed characters, which it fetched on
demand using
Service_International during its redraw loop. It then restored them
to their
original definition at the end of the redraw. This worked rather
well with
PostScript printing - the PostScript printer driver does a very
intelligent
job of handling system font and its redefinition. It doesn't yet
support
UTF8. Still.
Makes an amusing technical challenge, I reckon, so ZapRedraw does the
same thing when plotting in the system font. I think Browse would
reprogram the system font size too (using VDU 23,17,7 or whatever).
Good stuff.
--
Christian Ludlam
[EMAIL PROTECTED]
