Font ScanString & ConverttoOS queries

Using Font_ScanString to determine the bounding box for some text, I noticed an oddity which has caused some problems, and I am not sure if it a problem with FontManager or my code.

I use
SYS "Font_ScanString",handle%,rep%+36,flag%,-1,-1,rep%,,LEN text$
where
handle% is the font handle
rep%+36 holds the text$
flag% has bits 5, 7, 8 & 18 set so r5=block, r7=len, r0=font, return bounding block.
rep% area is zero, apart from +16 which is -1 for no split character.

This works fine when text$ contains some characters, but when it is null then the returned bounding box is &20000000,&20000000,&E0000000,&E0000000
which is 536870912,536870912,-536870912,-536870912

When passed through Font_ConverttoOS all these become -1342178 and it was this bounding box which caused problems.

Should scans of null strings be avoided? I can see no mention that it does not work but is seems likely.

Should Font_ConverttoOS return the same value for different inputs?

Not sure what text$="" and then SYS “Font_ScanString”,handle%,text$, … would actually do so how exactly do you obtain rep%+36?

Should scans of null strings be avoided? I can see no mention that it does not work but is seems likely.

Probably, yeah. It looks like it’s just returning the default values it initialises the bounding box to.

Should Font_ConverttoOS return the same value for different inputs?

Yes, Font_ConvertToOS should return the same value for some differing inputs (all it really does is a couple of integer divisions, so there are many inputs which will map to the same outputs).

But in this case it looks like you’ve breached the upper limit for the input range in which Font_ConvertToOS will work correctly. Looking at the source, it looks like it shifts the input values left two bits prior to the division so that it can calculate the sub-pixel position. So your upper and lower bounds both end up getting converted to &80000000.

@Chris: The exact code is
$(rep%+36)=text$
but why it uses that rather than just text$ in the SWI I have no idea … but both give the same result.

@Jeffrey: Thanks – I will investigate why null strings are being scanned, and avoid!
re ConverttoOS – yes, when it is essentially dividing by 400 there will obviously be same values, I meant for the two radically different values ScanString produced.

Perhaps there should be some notes added to both SWIs documentation about these restrictions?