Printing and additional offsets

An Ovation Pro user has reported what I believe is a bug in the printer
driver core and I have a fix for it.

When painting font strings, it is possible to pass a block which contains
additional shifts for space characters and for all characters. Note that a
space character gets the first x and y shifts as well as the second x and y
shifts. Anything else gets just the second x and y shifts.

https://www.riscosopen.org:8443/wiki/documentation/show/Font_Paint
https://www.riscosopen.org:8443/wiki/documentation/show/Font_ScanString

+0 Additional x offset for spaces
+4 Additional y offset for spaces
+8 Additional x offset for each letter
+12 Additional y offset for each letter

The bug is that if a string containing control codes is painted and the last
two values are non-zero, results on screen are correct and those on a printer
wrong.

Typically the additional shifts are used to implement justified text. The simple
approach is to increase the width of space characters. More advanced is to
increase both the width of spaces and other characters.

To see the problem, put some text in Ovation Pro, apply tracking to it (this
inserts a move after each character, using the font painter horizontal move
control code) and then justify the text, finally turn on enhanced
justification. The text will display correctly on screen but when printed
will have a ragged right edge.

The source of the trouble is that the printer driver is passed font paint
strings and splits them into pieces. The pieces are delimited by control
codes. It then uses Font_ScanString to measure the sizes of the pieces. But
whilst Font_ScanString adds the additional offset for spaces for the final
character when appropriate, it does not add the additional offset for each
letter for the final character.

The width of a string must be the same as the sum of the widths of its
substrings, and if Font_ScanString is used this will not be true.

The fix is to add one lot of the additional space for all characters to the
substring width returned from Font_ScanString.

In PSModules.s.Core.FontSWI, the code between the two DJP lines below:

fontswi_paint_nextposition
        Push    "R0-R7,LR"

        MOV     R7,R5                   ;Length of the section to be scanned

        ADR     R2,fontpaint_spaceaddX
        LDMIA   R2,{R3-R6}
        MOV     LR,#-1                  ;Split character is -1 (none)
        Push    "R3-R6,LR"              ;Push justification + split character

        LDR     R0,fontpaint_font       ;Get the handle of the font to be used

        LDR     R2,fontpaint_flags      ;Setup a valid flags word
      [ UCSText
        ;Ensure that UCS bits are preserved
        AND     R2,R2,#fontpaintflag_reversed +fontpaintflag_kern +fontpaintflag_matrix +fontpaintflag_16bit +fontpaintflag_32bit
      |
        AND     R2,R2,#fontpaintflag_reversed +fontpaintflag_kern +fontpaintflag_matrix
      ]
        ORR     R2,R2,#fontpaintflag_coordsblk +fontpaintflag_usehandle +fontpaintflag_length

        MOV     R3,#BigNum
        MOV     R4,#BigNum              ;Maximum offsets to get the caret position
        MOV     R5,SP                   ;Pointer to my coordinate block copy on the stack
        ADR     R6,fontpaint_matrix
        SWI     XFont_ScanString        ;Returns the nearest caret position to use as coordaintes

; start DJP
; R3,R4 X,Y coords
; SP-> addx,addy for spaces addx,addy for each letter
        LDR     R1,[SP,#8]
        ADD     R3,R3,R1
        LDR     R1,[SP,#12]
        ADD     R4,R4,R1
; end DJP
        ADD     SP,SP,#4*5              ;Balance the stack correctly
        BVS     fontswi_paint_nextpositionreturn

        ADR     LR,fontpaint_paintxy
        LDMIA   LR!,{R1,R2}
        ADD     R1,R1,R3
        ADD     R2,R2,R4
        STMIA   LR,{R1,R2}              ;Adjust the painting position correctly

fontswi_paint_nextpositionreturn

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.

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.

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).

too small to be noticeable

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.

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.