QDOS/SMSQE PRINT Procedure Whitespace issue

Anything QL Software or Programming Related.
User avatar
Artificer
Bent Pin Expansion Port
Posts: 98
Joined: Fri Nov 24, 2017 8:43 am

QDOS/SMSQE PRINT Procedure Whitespace issue

Postby Artificer » Thu Jul 30, 2020 8:23 pm

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
Super Gold Card
Posts: 607
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: QDOS/SMSQE PRINT Procedure Whitespace issue

Postby mk79 » Fri Jul 31, 2020 12:02 pm

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: 184
Joined: Fri Jan 13, 2012 5:29 pm
Location: Kent

Re: QDOS/SMSQE PRINT Procedure Whitespace issue

Postby EmmBee » Fri Jul 31, 2020 9:19 pm

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
Bent Pin Expansion Port
Posts: 98
Joined: Fri Nov 24, 2017 8:43 am

Re: QDOS/SMSQE PRINT Procedure Whitespace issue

Postby Artificer » Sat Aug 01, 2020 10:57 am

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: 1084
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: QDOS/SMSQE PRINT Procedure Whitespace issue

Postby NormanDunbar » Sat Aug 01, 2020 4:07 pm

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 6 times

Assembly_Language_003.pdf
(302.99 KiB) Downloaded 7 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 - https://www.amazon.co.uk/Arduino-Softwa ... 1484257898, https://www.apress.com/gb/book/9781484257890
User avatar
Artificer
Bent Pin Expansion Port
Posts: 98
Joined: Fri Nov 24, 2017 8:43 am

Re: QDOS/SMSQE PRINT Procedure Whitespace issue

Postby Artificer » Sat Aug 01, 2020 7:41 pm

Hi Norman,

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

Cheers


martyn_hill
Super Gold Card
Posts: 570
Joined: Sat Oct 25, 2014 9:53 am

Re: QDOS/SMSQE PRINT Procedure Whitespace issue

Postby martyn_hill » Sun Aug 02, 2020 6:28 pm

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
Bent Pin Expansion Port
Posts: 98
Joined: Fri Nov 24, 2017 8:43 am

Re: QDOS/SMSQE PRINT Procedure Whitespace issue

Postby Artificer » Mon Aug 03, 2020 6:53 am

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
QL Wafer Drive
Posts: 1963
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: QDOS/SMSQE PRINT Procedure Whitespace issue

Postby tofro » Fri Aug 07, 2020 10:56 am

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

Who is online

Users browsing this forum: No registered users and 9 guests