Printing and additional offsets
David Pilling (8394) 93 posts |
An Ovation Pro user has reported what I believe is a bug in the printer When painting font strings, it is possible to pass a block which contains https://www.riscosopen.org:8443/wiki/documentation/show/Font_Paint +0 Additional x offset for spaces The bug is that if a string containing control codes is painted and the last Typically the additional shifts are used to implement justified text. The simple To see the problem, put some text in Ovation Pro, apply tracking to it (this The source of the trouble is that the printer driver is passed font paint The width of a string must be the same as the sum of the widths of its The fix is to add one lot of the additional space for all characters to the In PSModules.s.Core.FontSWI, the code between the two DJP lines below:
|
nemo (145) 2496 posts |
I don’t think it’s quite that simple, and it doesn’t just apply to the unusual case of tracking – it affects all kerned fonts when there’s a ctrl sequence in the middle of a kern pair. I had to work around ScanString’s unhelpful results when calculating character bounding boxes with tracking, kerning and cursor move ctrl sequences, so I’m aware of the issues: The problem is caused by the truncation at control code sequences using the ‘R7’ parameter. Crucially, ScanString does access the character at R7 at the end of the substring, but fails to adjust the advance according to what it finds (and if truncated at a ctrl sequence it wouldn’t be the relevant character anyway). It has always done this. However, applying the spacing manually as you’ve done above should only occur when the next character after the control code sequence(s) is a printable. If it’s any kind of terminator then no adjustment should occur (as it would affect the rubout, among other things). And the above suggestion does not deal with the trickier case of kerning pairs either. What I had to do (demonstrated in the GIF above) is build a string with the next printable (and without the ctrl sequence) to find its combined advance width – with tracking, spacing and kerning – then subtract the advance of that printable. Very nasty. |
David Pilling (8394) 93 posts |
Anything that inserts control codes will trigger the problem I see – changing colour, font, putting in comments, manual x and y shifts, super/sub-scripts. Usually the effect will be too small to be noticeable. Tracking a chunk of text gets a big effect. There are oddities in Font_ScanString, in the OP source code there’s a note from 2008 saying how the code had to be changed to work around them. For that reason I take the behaviour of Font_ScanString as given. The issue is making the printer results agree with those on screen. Thanks for spotting the bug in my fix – I’ll try to escape, by suggesting that in the printer driver this code is only called for pieces of entirely printable text. |
nemo (145) 2496 posts |
Yes, any ctrl code that interrupts a character pair that does cause a cursor positioning adjustment in Font_Paint (space-width, tracking or kerning) will be defeated by splitting the string before the second character. The technique is not compatible even with kerned fonts (One might argue whether kerning ought to occur when a DX/DY cursor movement has occurred, but that’s academic now).
Try introducing a colour change between “T” and “r” in a kerned font like Trinity (with kerning enabled, obvs). As I say, the space/track/kern error can be calculated for the string “A<ctrls>Z” by scanning the advance of “AZ” and subtracting the advance of “Z” – obviously if the ctrls involve a DX/DY (or much worse matrices, which for some reason don’t concatenate!) the calculation is more involved. |
David Pilling (8394) 93 posts |
I’d commend my fix because it is very simple and what it changes is limited – there are not going to be lots of bugs spilling out over unforeseen areas. I have reproduced the problems with auto kerning in Ovation Pro – where there is auto kerned text with font manager control sequences between the pairs of characters then printed and on screen results differ. Some control sequences cancel auto kerning e.g. change of font or font size, others don’t e.g. change of colour. The problems we’re talking about here are present in the Acorn PostScript and bitmap drivers. I worked out how I would add code to fix both the additional shift and the auto kerning problem. What has upset this plan is information about the situation with the Martin Wuerthner level 3 PostScript driver. This apparently has the problem with additional shifts, but does not have the problem with auto kerning. End of the matter as far as I am concerned. |