Text alignment in generated PDFs (print card from ... to... into...)

Ben Rubinstein benr_mc at cogapp.com
Fri May 15 07:53:08 EDT 2026


I very nearly followed this.

But I think there are some amends needed to the Dictionary.

I will endeavour to get my thoughts straight on this, and write a report to 
the QCC.

thanks,

Ben

On 13/05/2026 15:50, Mark Waddingham via use-livecode wrote:
> On 2026-05-12 18:35, Ben Rubinstein via use-livecode wrote:
>> I have a stack which generates a PDF report.
>>
>> Printing is opened using
>>        set the printPaperOrientation to "landscape"
>>           set the printPaperScale to 0.60
>>       open printing to pdf <filename>
> ...
>> The Dictionary entry for open printing doesn't mention the "... to pdf 
>> <filename>" syntax. Although not linked from the entry for "open printing", 
>> the Dictionary does have an entry for the "printerOutput" property, which it 
>> says can be given a few different values, including
>>
>>      file - <filename> : output to the given file. The format of the file 
>> depends on the platform:
>>
>>     preview - output to print preview (only supported on Mac OS X).
> 
> I should perhaps clarify - there are indeed two separate things here...
> 
> There is the system printer path, and the pdf printer path.
> 
> The system printer path is platform-dependent* - it uses the system printer. 
> On macOS this is PDF based as in the system printer on macOS uses PDFs as the 
> spool format; on Windows this is not PDF based, it uses some Windows-specific 
> format I can't remember the name of; on Linux it uses the pdf printer because 
> the system printer stuff there is basically 'give me postscript or pdf and 
> I'll do something sensible with it', rather than having a higher-level set of 
> drawing primitives which then hide the creation of said spool format under the 
> hood.
> 
> This is why the system printer (what you get when don't use 'to pdf') on macOS 
> can preview and generate files which are PDFs.
> 
> The pdf printer path, which is a cross-platform component which does its own 
> pdf generation and does not use system printing APIs, is what you get when you 
> do 'to pdf' (in principal, assuming the font files on two systems regardless 
> of platform are the same, then printing to pdf on those platforms will 
> generate identical results).
> 
> Warmest Regards,
> 
> Mark.
> 



More information about the use-livecode mailing list