Print to Draw

I should like to print to a Draw file, one for each page. Is there such a thing as a printer driver that outputs each page to a Draw file?

Alternatively is there a convertor that would convert a Postscript file to a Draw file?

Producing a PDF then importing it to ArtWorks (which can then export a Draw file) suffers from the limitations in ArtWorks that only Trinity and Homerton fonts are recognised as themselves. Garamond is converted to Trinity. Selwyn is ignored.

Any ideas please?

!PDF, perhaps?

!PDF, perhaps?

I use this extensively for manipulating music sheets, but haven’t had occasion to check-out any “fancy” fonts.

haven’t had occasion to check-out any “fancy” fonts.

I’ve just tested the PDF viewer’s ‘Save as Drawfile’ option, and unfortunately it failed to replicate a random selection of non-RO-standard fonts. The only workarounds that come to mind at present are 1. create the original document using Artworks and convert the fonts to shapes; 2. view the PDF using MuView (the only RISC OS pdf viewer I know which renders with 100% accuracy) and save out a Sprite file. This however will lose the character definition – ‘sharpness’ – intrinsic to the PDF.

Chris wished

print to a Draw file

Absolutely. It’s been on my todo list for 25 years and really ought to be easy, as printer drivers go.

I’ve never got around to it, but I’ve underlined it in red pen so…

[Edit] Ah yes I remember, the difficulty is the lack of clipping in standard Draw files. Not a problem for Vantage but no good for plain old !Draw.

failed to replicate a random selection of non-RO-standard fonts.

I wonder if it might work to hack the created DrawFile to put the desired font names back in again…?
Or does it just make a mess where everything gets degraded down to either Homerton or Trinity (as in, messing up all of the font references?).

Have you tried asking Martin Würthner? It might be possible to get ArtWorks to look up what fonts are available on the system rather than assuming the standard ones…?

Via PostScript to PDF is one method, but as mentioned above the preservation of font data is a problem. If preserving the text as Drawfile text objects (a type 1 object) is not important, then it is possible to convert the text to paths, retaining the correct appearance of the fonts. I don’t know of anything on RISC OS to do this, but I regularly use Acrobat Pro (on Windows) to convert all text to paths, then re-import into !ArtWorks (or !PDF and save as Drawfile) for further editing.

Many years ago, there was !RiScript. IIRC it could take PostScript files and PDFs and convert to Drawfiles. I can’t remember how good it was at handling/converting embedded fonts. I don’t think it was ever 32-bitted (although I may be wrong). I don’t know if it would work under Aemulor.

On the subject of font/text data being sent through to PostScript (with the view to it being eventually editable in a Drawfile, if such conversion could be done). There is often a possibility that a string of text output from an application (such as Ovation Pro) would be split up into many separate characters, making it almost impossible to re-edit that line of text properly in an editor such as ArtWorks or Draw etc.

This can often happen if there is particular styling or effects applied to the text, such as kerning or tracking. If you look at the PostScript output you can often see each single character as a string in parentheses preceded with coordinates to place the character in the correct position on the page. So even if you do manage to convert the PostSript to a Drawfile containing text objects in the appropriate RO font, you could end up with a page full of single characters, making further text editing difficult.

If it’s just for rendering the output then I guess that doesn’t really matter too much.

@Jon W
You are using !PMS/PMW and it builds eps files.
Fonts are encoded in the file.
Printing to !PDF does not display the notes, as they are in the PMS alpha or music font by Richard Hallas.

!PDF, perhaps?

!PDF does an excellent job but translates Garamond to Trinity and ignores Selwyn. It then outputs Draw files (one for each page) where every character is a separate text object. I assume that is because the Postscript level 3 drivers and the ps2pdf command produce the text in that way inside the PDF.

where every character is a separate text object. I assume that is because the Postscript level 3 drivers and the ps2pdf command produce the text in that way inside the PDF.

It would depend on what app it was originated in when it was printed to PostScript.

Edited to add, for example, if you printed from Draw, a text object (type 1) then it would probably appear as the full string in the PostScript output.

I should like to print to a Draw file, one for each page.

What file format or app are you starting from, and what do you want to do with the resulting Draw files? I assume it must be more than just printing them.

Garamond is converted to Trinity

Sounds like a plus point to me :-) (sorry, pathological hatred of Garamond)

@Jon W (@J_M: Who?)
You are using !PMS/PMW and it builds eps files.

I am editing/manipulating PDF files from the internet such as to be found here and where text is rendered as individual character objects, but these can be grouped for deletion or manipulation, but not edited as strings. Individual character objects can be “edited” – replaced – and have their fonts changed.

So a multiple selection of characters can have their properties altered, but changing the font size messes things up so that characters overlap or are too widely spaced. Once objects are grouped, this is no longer possible.

Some scanners may produce “proper” PDF files which may be similarly “edited”, but within these limitations. If the characters are rendered as single objects then they can be deleted and/or replaced in the Draw file.

So this means practically that to change text font one has to retype the line in the font required and adjust the size to suit the format.

pathological hatred of Garamond

Oh, wow, okay.
Typing Garamond into Google changed Google to Garamond.

I don’t know if it’s the phone screen, but to my eyes it looks a little too “fine”, like it would be rather tiring to read for any length of time.
Perhaps it’s better on paper, but it comes across as a rather fiddly serif font. Thanks, I’ll stick with Times/Trinity.

Actually, I rather like the aesthetics of ComicsSans/Sassoon ¹ but a couple of decades ago, so did everyone else so now a good readable font is unfortunately derided as being crap.

¹ It’s a very clear and easy to read font without the harsh brutality of the likes of Verdana. It’s a soft font, while the big harsh sans serif ones are for screamy headlines and placards about stopping boats.

Typing Garamond into Google changed Google to Garamond.

Indeed it does, to my surprise. But it doesn’t change to Bembo when you type Bembo.
Contrary to John, I love Garamond, while Bembo is even my personal default font in OvationPro.
By the way, if you look for a nice, clean and perfectly readable font, try GillSans. It is my desktop font since ages.

But let’s return to the subject, which I don’t know a solution for.

What file format or app are you starting from, and what do you want to do with the resulting Draw files? I assume it must be more than just printing them.

Original is 368 pages in Impression Publisher Plus and the resulting Draw files are to be used by RingBind. At present I am having to manually add Selwyn characters.

[Edit] Ah yes I remember, the difficulty is the lack of clipping in standard Draw files. Not a problem for Vantage but no good for plain old !Draw.

Why is clipping an issue? So long as the page size is set correctly, any objects in negative coordinates don’t appear when the file is opened and any that are outisde the paper size can be ignored.

At present I am having to manually add Selwyn characters.

I’d be happy to run the pdf through Acrobat to convert all text to paths for you, if that’s of any help.

Converting text to paths would not help. But thanks anyway.

Thanks John Williams for the link.
I am interested, I play the violin with my grandchildren.

!PDF allows you to retrieve the scores in !Draw, the notes text are drawings not Fonts.

Advertisement (not a spam) :-)
< Advertisement (not a spam) :-)
With SharpEye, it’s very easy to retrieve these scores and create a !Pms or !Rhapsody file >

Why is clipping an issue?

Because the VDU supports graphics windows which are used in the print API directly and by any application that wishes to during printing. These map through to PostScript easily, and are directly supported when rendering to an intermediate bitimage, but there is simply no “clipped” object in DrawFile format as standard.

So stuff in frames would spill out. There is a clipped object wrapper in Vantage drawfiles, which is of no assistance in this case.

Having to clip within the printer driver is hard work because it would in general require generating high resolution sprites (not least because standard sprites don’t support having a high resolution mask with a lower resolution content).

Garamond

“Garamond” is a generic (unlike “Times”), so there’s 500 different versions of different sizes, weights, slants, optical size and aroma, probably.

Clipping bitmaps at the next pixel beyond the ‘edge’ of the frame would probably not be noticeable. I think clipping of vector graphic images is more problematic, as you say. The vast majority of vector graphic images are wholly contained within the frame they occupy. Also text is almost always within its frame. So there is a lot that could be done that would work for the majority of pages in a document.

!PDF does a good job at exporting Draw files from a PDF. It is a pity that it sometimes gets the fonts wrong: it allocates 14 fonts on each page (the PDF uses 14 fonts) but gets some font numbers in text objects consistently wrong – for example Selwyn is 14 but text objects using Selwyn get given font number 5 (Homerton.Medium) in every case. This means that it renders Selwyn as Homerton in its display on screen as well.

Chris commented

Clipping bitmaps at the next pixel beyond the ‘edge’ of the frame would probably not be noticeable.

It is when they’re 4dpi at 45 degrees.

The vast majority of

There only needs to be one.

!PDF

Is evidently broken.