The Sinclair QL Forum

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

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

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

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

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.
It might be useful?


Cheers,
Norm.

Hi Norman,

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

Cheers

Hi there.

Just wondering what range of values the two parameter strings & could take in your PRINT statement:
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...

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

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