text awol when printed

I’ve recently re-encountered an old problem so I thought I’d raise it here to ask for it to get attention and a fix.

When I tried printing a drawfile containing (Homerton) text, all the non-text items appeared, but none of the text. I used OpenVector with Printers 1.77 on my ARMiniX (RO 5.21 R-Comp version). Discussing this on the ARMini/X list it is clear that others get the same symptom at times with various software, etc. So it does seem a bug somewhere like in Printers. I’m using a Canon 4300 inkjet, not a PS printer.

I’ve also had this (as have others) when trying to print PDFs, so the common factor does seem the printing area.

I have encountered this in the distant past when I used a Calligraph direct printer. But I’ve only re-encountered it a few times relatively recently. IIRC in ye olde days !FontFix might fix it. But I’ve not tried that as yet for my present system.

Jim

I thought I’d raise it here to ask for it to get attention and a fix

That’s slightly idealistic, you can raise it but the other 2 things expand more like “is it real” then “who is capable” and “do they want to”. In this instance, I can probably help with the “is it real” step – for me at least missing text is 100% repeatable, but I’ve never been able to spot what’s actually wrong.

The specific use case I have is some manuals for BBC micro upgrades where there’s the occasional illustration that came many moons ago from !Draw. These are saved within !TechWriter documents, and on printing the main body text comes out, the line art from the draw diagram too, but not text within the draw diagram. Here’s a simple test.

I’ve noted that sending it to a postscript file works (I can see the text strings in the output postscript).
I’ve noted that if I RMKill DrawFile after running Techwriter (to force TechWriter to draw it itself) the text comes out OK.
In the printing stack there’s MyDoc → DrawFile → PDriver → PDriverDP → PDumperWhatEver.

Since the dumpers just print strips of dots out and PDriver is common to the (working) postscript case it’s a 50/50 bet as to DrawFile or PDriverDP messing up, with a small each way bet on FontManager just to be safe.

Perhaps use this thread and the above test document to do some test printouts and report which versions of everything are in use. Note, the version of PrinterManager isn’t important, it doesn’t actually print the image.

In the printing stack there’s MyDoc → DrawFile → PDriver → PDriverDP → PDumperWhatEver.

Question:
Doesn’t that become MyDoc → DrawFile → PDriver → PDriverPS for the Postscript case?
If so the first changed item in the chain is PDriverDP becoming PDriverPS.

Doesn’t that become MyDoc → DrawFile → PDriver → PDriverPS for the Postscript case?
If so the first changed item in the chain is PDriverDP becoming PDriverPS.

Very true, my ASCII art pipeline isn’t quite how the printing system passes data, so I can’t eliminate DrawFile even though that might have been implied.

DrawFile calls the Font SWIs to plot the text which are being intercepted by PDriverDP or PDriverPS – in the PS case it keeps them as text and shoves them into the postscript, in the DP case it calls the font manager to turn them into a bitmap.

It could be that (for example) the string to paint is being constructed on the stack and PDriverPS is happy with that but font manager isn’t. Top bit set pointers are a strong theory as to the cause, but this happens on RISC OS 4.02 as well where the SVC stack is in the low half of memory, and I don’t think TechWriter uses a dynamic area (which could be top bit set on RISC OS 4).

Fair comment on ‘idealist’. But I can at least hope for a solution! :-)

Beyond that I can’t comment much on the above discussion beyond saying that I’ve also noticed on occasion that a DrawFile that fails to get its text printed by something like OpenVector works OK when printed by TechWriter. However I’ve never been able to determine any systematic differences that affect this, and it is a problem I only encounter on occasion. Classic example of a ‘rare intermittent fault’ of the kind that always hides when the repairman vists. :-/

IIRC though !FontFix did correct a similar symptom years ago. But I’ve no idea what the cause was then, or if that might be relevant at all now.

I presume this bug has lasted so long because it is so irratic, making it hard to nail down, and usually ‘not a problem’ because it isn’t happening most of the time.

Jim