QDOS/SMSQE PRINT Procedure Whitespace issue

Anything QL Software or Programming Related.
Post Reply
User avatar
Artificer
Brittle Membrane
Posts: 120
Joined: Fri Nov 24, 2017 8:43 am

QDOS/SMSQE PRINT Procedure Whitespace issue

Post by Artificer »

Hi All,

I have been writing a Quill doc to .ps file filter in SBASIC. The filter retains document format and font selection/output of font type in the .ps output file.

I have found something which is puzzling. Which is that when a string that is entirely composed of CHR$(32) is output using the PRINT(#ch) keyword to either a pipe or to an output file that the string is shrunk regardless of length or what follows in the same line, to a CHR$(10).

This results in paragraph headers that were centered in the Quill .doc using CHR$(32) misplaced to the left margin. This seems to be something that is inherent in the PRINT procedure keyword in QDOS and smsqe. Why is that so? I am not looking for a solution for my program as I have a simple fix, but it seems to be built into QDOS/smsqe that strings contain only CHR$(32) are treated differently from similar strings that contain some visible printable characters.

Any ideas. I have had a look at the original QL SuperBASIC by Jan Jones, The Sinclair QDOS companion, and the SBASIC/Superbasic Reference Manual.

Thanks

Cheers


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: QDOS/SMSQE PRINT Procedure Whitespace issue

Post by mk79 »

Artificer wrote:I have found something which is puzzling. Which is that when a string that is entirely composed of CHR$(32) is output using the PRINT(#ch) keyword to either a pipe or to an output file that the string is shrunk regardless of length or what follows in the same line, to a CHR$(10).
Do you have any code to reproduce the behaviour? I find that highly unlikely and as far as I can see there is nothing in the PRINT source code that does anything like this.

Cheers, Marcel


EmmBee
Trump Card
Posts: 240
Joined: Fri Jan 13, 2012 5:29 pm
Location: Kent

Re: QDOS/SMSQE PRINT Procedure Whitespace issue

Post by EmmBee »

Artificer wrote: I have found something which is puzzling. Which is that when a string that is entirely composed of CHR$(32) is output using the PRINT(#ch) keyword to either a pipe or to an output file that the string is shrunk regardless of length or what follows in the same line, to a CHR$(10).
My guess is you're probably leaving out the required trailing semi-colon ";" and are using something like ... PRINT #ch, FILL$(" ",n)
Without any following print separator, PRINT will add a CHR$(10) and will print the number of spaces, and then a newline.
Because only invisible spaces are being displayed, you don't notice them.
To leave the print position after the spaces, use ... PRINT #ch, FILL$(" ",n);

EmmBee


User avatar
Artificer
Brittle Membrane
Posts: 120
Joined: Fri Nov 24, 2017 8:43 am

Re: QDOS/SMSQE PRINT Procedure Whitespace issue

Post by Artificer »

Hi

Here is the scenario, it is complex. I am working with 2 filters written in SBasic to convert Quill doc files to postscript files to print via CUPS on a RPi to my wifi printer. The first filter converts the Quill doc to formatted text in paragraphs with a paragraph font map. It then PRINTs each paragraph as lines or line segments with attached font info via a pipe to the second filter. The second filter is derived from Marcel's MPS.bas. This uses INPUT to fetch each line and create the postscript line from this information. The second filter then outputs the postscript line to the RPi via ser1.
The Rpi via Python collects each line of postscript into a file and when the document is finished sends it off to the printer.

The line that caused my question uses white space (CHR$(32)) to centre a paragraph title. The title is in bold text. The whitespace is in Quills normal text. The first filter splits the line at the first bold character so PRINTs txt$ equivalent to 30xCHR$(32) to the pipe followed by the title text "ScrapMC" preceded by a flag to indicate to the postscript filter to use the bold font for these characters. What is happening is that the output postscript file has the title text in bold at the left margin instead of centered, the whitespace has got lost somewhere between the 2 filters. Now it could easily be my code but the solution is as Emmbee points out is to terminate the CHR$(32) string with another character. I used CHR$(0) which is easily found and stripped off in the second filter.

The code for both parts of the line is essentially PRINT#outpipech%,font_flg$&margin$&txt$ > INPUT#inpipech%,line$ : The code font_flg$ for normal text is CHR$(250), margin$ is the margin position in Quill - could the font_flg$ be the problem?

Essentially my question is a bit academic as I have a solution but I do not understand what the problem was.
At the moment the filters are being tested with a variety of Quill docs to find anomalies like this and in a bit I plan to merge the 2 filters.

Thanks for taking an interest

Cheers


User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: QDOS/SMSQE PRINT Procedure Whitespace issue

Post by NormanDunbar »

Afternoon Artificer,

I am wondering if "something else" is getting transmitted between filters. In Issue 3 of my somewhat irregular eComic on Assembly, there's a filter to hexdump whatever is sent to it, that might perhaps show up exactly what is being sent to the filter/out of the filter?

If so, the PDF and the asm and binary files are attached. The zip file was created on Linux, so you might need to fiddle the headers in the normal manner.
Hexdump.zip
(6.31 KiB) Downloaded 122 times
Assembly_Language_003.pdf
(302.99 KiB) Downloaded 115 times

Code: Select all

ex Hexdump_bin, input file or channel, output file or channel
It might be useful?


Cheers,
Norm.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
Artificer
Brittle Membrane
Posts: 120
Joined: Fri Nov 24, 2017 8:43 am

Re: QDOS/SMSQE PRINT Procedure Whitespace issue

Post by Artificer »

Hi Norman,

Thanks for that suggestion. I will have a look at what is going through the pipe with your programs.

Cheers


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QDOS/SMSQE PRINT Procedure Whitespace issue

Post by martyn_hill »

Hi there.

Just wondering what range of values the two parameter strings

Code: Select all

font_flg$
&

Code: Select all

margin$
could take in your PRINT statement:

Code: Select all

PRINT#outpipech%,font_flg$&margin$&txt$
Specifically, could either string contain a CHR$10 that would upset the INPUT at the other end of the pipe?

Whilst I can't see how this would translate in to hard-spaces 'condensed' in to a newline, it might account for the two halves of each filter getting out of sync with one another...


User avatar
Artificer
Brittle Membrane
Posts: 120
Joined: Fri Nov 24, 2017 8:43 am

Re: QDOS/SMSQE PRINT Procedure Whitespace issue

Post by Artificer »

Hi Martyn

Neither font$ or margin$ could contain CHR$(10). font$ values range from CHR$(249) to CHR$(255). margin$ is just FILL$ CHR$(32) whatever the margin setting is in the Quill doc.

I am planning to have a look at what Norman Dunbar's hexdump filter captures, which should tell me which end of the pipe the problem occurs.

Thanks for taking an interest.

Cheers


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: QDOS/SMSQE PRINT Procedure Whitespace issue

Post by tofro »

While it's true that QDOS doesn't have any concept of "Output width" in lines for channels, S*BASIC has - The S*BASIC channel table holds a variable that is expected to contain the line width of the channel, and affects the PRINT command when used with separators - ("!" and ",") whether or not to break a line with CHR$(10).

You can set this output line length with the WIDTH command, for "non-windows" (If a channel is associated with a screen window, WIDTH is ignored in favour of the window width).

Maybe your problem is somehow associated with this "assumed width".


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Post Reply