NetSurf's Draw files
Harriet Bazley
of some sort had subsequently come up for this, but I haven't been able
to locate it.
In a nutshell, I can't export Draw files saved out of NetSurf on the
Iyonix to any other computer because they have UTF fonts specified in
them. I think I used to use Netsurf's internal PDF export to help with
this, but it's been disabled in the latest versions for a while.
'Printing' such Draw files via PrintPDF apparently creates invalid
PostScript for the same reason,
GPL Ghostscript 8.54 (2006-05-17)
Copyright (C) 2006 artofcode LLC, Benicia, CA. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /undefined in #
Operand stack:
Acorn_UTF8Encoding --nostringval--
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop --nostringval-- 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval--
Dictionary stack:
--dict:1053/1123(ro)(G)-- --dict:0/20(G)-- --dict:74/200(L)-- --dict:103/200(L)-- --dict:74/200(L)--
Current allocation mode is local
Last OS error: 2
Current file position is 8169
GPL Ghostscript 8.54: Unrecoverable error, exit code 1
while using PrintPDF directly from NetSurf yields "An error occurred
while printing: redraw error".
Didn't someone produce a utility a while ago that simply edited such
Draw files to remove the UTF references, since in most cases the text
contained is perfectly standard ASCII? I've tried manually editing the
font strings in the Drawfile, but Draw doesn't like the result - I
assume the header format is a little more sophisticated than that!
--
Harriet Bazley == Loyaulte me lie ==
Nostalgia isn't what it used to be.
Matthew Phillips
on 23 May 2010 Harriet Bazley wrote:
> Didn't someone produce a utility a while ago that simply edited such Draw
> files to remove the UTF references, since in most cases the text contained
> is perfectly standard ASCII? I've tried manually editing the font strings
> in the Drawfile, but Draw doesn't like the result - I assume the header
> format is a little more sophisticated than that!
DrawPrint (see http://sinenomine.co.uk/software/ ) uses this technique to
remove UTF font encoding before using the DrawFile module to render and print
the output. It's one of the options in DrawPrint's choices. It also does
various other things to avoid bugs with the NetSurf output (possible fixed
now) and the DrawFile module when printing files with a large area.
However, there's no option to export the Draw files: they're created
internally in the application but are not exportable in the current version.
If you drop a Draw file from NetSurf on to DrawPrint and printed that using
PrintPDF then you could probably transfer that file successfully to other
machines.
Is this along the lines of what you are trying to do?
--
Matthew Phillips
Dundee
Harriet Bazley
Matthew Phillips wrote:
[snip]
> If you drop a Draw file from NetSurf on to DrawPrint and printed that using
> PrintPDF then you could probably transfer that file successfully to other
> machines.
>
> Is this along the lines of what you are trying to do?
>
Hope so - I'll try it!
--
Harriet Bazley == Loyaulte me lie ==
A closed mouth gathers no foot.
Christopher Martin
Harriet Bazley <baz...@feathermail.co.uk> wrote:
> I can't export Draw files saved out of NetSurf on the Iyonix to any
> other computer because they have UTF fonts specified in them.
Recent releases of DrawPlus/OpenVector deal with this by simply dropping
the "\EUTF8" from the fontname. So if the page contains genuine UTF8
characters, the drawfile will not display them properly as NetSurf does.
But it may be good enough for what you need.
<http://www.users.on.net/~belles/software/openvector/>
--
Regards, Chris.
Harriet Bazley
> In message <38f4f71b5...@blueyonder.co.uk>
> Harriet Bazley <baz...@feathermail.co.uk> wrote:
>
> > I can't export Draw files saved out of NetSurf on the Iyonix to any
> > other computer because they have UTF fonts specified in them.
>
> Recent releases of DrawPlus/OpenVector deal with this by simply dropping
> the "\EUTF8" from the fontname. So if the page contains genuine UTF8
> characters, the drawfile will not display them properly as NetSurf does.
Ah. That reveals that there *are* in fact UTF8 characters in the file
in question - mainly hard spaces, I think.... At least now I can
presumably get rid of them!
--
Harriet Bazley == Loyaulte me lie ==
But what we need to know is, do people want nasally-insertable computers?
Harriet Bazley
> On 24 May 2010 as I do recall,
> Christopher Martin wrote:
>
> > In message <38f4f71b5...@blueyonder.co.uk>
> > Harriet Bazley <baz...@feathermail.co.uk> wrote:
> >
> > > I can't export Draw files saved out of NetSurf on the Iyonix to any
> > > other computer because they have UTF fonts specified in them.
> >
> > Recent releases of DrawPlus/OpenVector deal with this by simply dropping
> > the "\EUTF8" from the fontname. So if the page contains genuine UTF8
> > characters, the drawfile will not display them properly as NetSurf does.
>
> Ah. That reveals that there *are* in fact UTF8 characters in the file
> in question - mainly hard spaces, I think.... At least now I can
> presumably get rid of them!
>
It works: and more impressively, DrawPlus 3.30 turns out to work under
RISC OS 3.1, as well. (With a little doctoring of the !Run file: for
some reason, the Wimpslot has been specified as "-min 452K -max 376K",
which means that you actually *get* 376K under RISC OS 3.1 rather than
452K, and it isn't enough.) What it doesn't do is print under
TurboDrivers ("System variable 'FileSwitch$Resources$CSD' not found" -
what is this supposed to point to? There doesn't seem to be any such
system variable on the Iyonix either, but DrawPlus doesn't object
there), but the 'old' version (2.50) turns out not to do this either.
Obviously I never actually tried to print anything directly out of
DrawPlus!
I thought that I couldn't see any indication while dragging, but the
reason for this turned out to be that I was dragging very small objects
(bullet points), and the 'hand' pointer shape was obscuring them....
Everything else seems to work O.K.
I even printed out the original manual, but this doesn't answer one
question which (in the absence of an Undo function) has been troubling
me for some time: how does DrawPlus choose which object[s] to move when
you give it an Align command? Does it depend on the position in the
stack, or the order in which they are selected, or some other factor?
About ninety per cent of the time attempting to align objects does what
I expect it to, but every so often things get aligned to the 'out of
position' object I'm trying to correct instead!
--
Harriet Bazley == Loyaulte me lie ==
If you're feeling good, don't worry. You'll get over it.
Christopher Martin
Harriet Bazley <harriet...@blueyonder.co.uk> wrote:
> It works: and more impressively, DrawPlus 3.30 turns out to work under
> RISC OS 3.1, as well. (With a little doctoring of the !Run file:
> for some reason, the Wimpslot has been specified as "-min 452K -max
> 376K", which means that you actually *get* 376K under RISC OS 3.1
> rather than 452K, and it isn't enough.)
Noted. I'll make sure that I set the max to the min for the next release
(3.30 beta 5, or higher). I didn't know that RISC OS 3.1 prevents the
apps from extending the wimpslot. The app only needs 376K to load and
start running whereupon it will extend the wimpslot to 452K as it
creates the dynamic data structures it needs. On later versions of RISC
OS, the -min > -max arrangement serves to check that a reasonable amount
of memory is available without grabbing it all up-front. I habitually
use this arrangement with other apps that are more frugal with memory.
But in DrawPlus' case, it doesn't matter so I'll set -max = -min.
> What it doesn't do is print under TurboDrivers ("System variable
> 'FileSwitch$Resources$CSD' not found" - what is this supposed to point
> to?
Hmmm... Don't know what this is about. I'll have to look into it.
> I thought that I couldn't see any indication while dragging, but the
> reason for this turned out to be that I was dragging very small
> objects (bullet points), and the 'hand' pointer shape was obscuring
> them.... Everything else seems to work O.K.
But you might want to download beta 4 now, released a few hours ago.
> I even printed out the original manual, but this doesn't answer one
> question which (in the absence of an Undo function) has been troubling
> me for some time: how does DrawPlus choose which object[s] to move
> when you give it an Align command? Does it depend on the position in
> the stack, or the order in which they are selected, or some other
> factor? About ninety per cent of the time attempting to align objects
> does what I expect it to, but every so often things get aligned to the
> 'out of position' object I'm trying to correct instead!
In the absence of locked objects, alignment moves objects to: (1) the
furthest edge (in the case of top/bottom/left/right); or (2) to the
centre-line of the object whose centre-line is closest to the whole
selection group's centre-line (in the case of H/V centre). The former is
straightforward but the latter can be difficult to judge.
OpenVector allows better control by alignment to (or packing around)
locked objects.
I guess I will need to put together a proper manual sometime. But anyone
is welcome to take the CHANGES file from the download page and make a
more readable version.
--
Regards, Chris.
Jess
Christopher Martin <bel...@internode.on.net> wrote:
> In message <33aea01c5...@blueyonder.co.uk>
> Harriet Bazley <harriet...@blueyonder.co.uk> wrote:
>
>> It works: and more impressively, DrawPlus 3.30 turns out to work under
>> RISC OS 3.1, as well. (With a little doctoring of the !Run file:
>> for some reason, the Wimpslot has been specified as "-min 452K -max
>> 376K", which means that you actually *get* 376K under RISC OS 3.1
>> rather than 452K, and it isn't enough.)
>
> Noted. I'll make sure that I set the max to the min for the next release
> (3.30 beta 5, or higher). I didn't know that RISC OS 3.1 prevents the
> apps from extending the wimpslot. The app only needs 376K to load and
> start running whereupon it will extend the wimpslot to 452K as it
> creates the dynamic data structures it needs. On later versions of RISC
> OS, the -min > -max arrangement serves to check that a reasonable amount
> of memory is available without grabbing it all up-front. I habitually
> use this arrangement with other apps that are more frugal with memory.
> But in DrawPlus' case, it doesn't matter so I'll set -max = -min.
Isn't it just the values are the wrong way round?
--
Jess Iyonix