high resolution when printing to pdf, either from images or pdf widgets

[doc hawk]

On Sep 7, 2019, at 4:29 AM, Mark Waddingham via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> On 2019-09-06 21:10, Dr. Hawkins via use-livecode wrote:
>> On Aug 28, 2019, at 12:07 AM, Mark Waddingham via use-livecode
>> <use-livecode at lists.runrev.com> wrote:
>>> On 2019-08-27 17:24, Dr. Hawkins via use-livecode wrote:
>>> I'm not entirely clear what Monte meant by 'print to pdf directly' in one
>>> of those comments... The 'print to pdf' mechanism in the engine isn't
>>> really any different from the normal printing mechanism, its just that
>>> rather than funnel the sequence of paths, images, text being rendered
>>> through the system printer it funnels it through libcairo's (https://cairographics.org/)
>>> PDF output functionality.
>> Can this be adjusted for higher resolution?
>> *is* there a way to send out at full resolution?
> 
> I'm not sure I entirely follow - PDF is primarily a vector format so there is
> 'resolution' as such. In regards to images then the engine/pdfprinter tries
> to preserve the original image when printing - so if you print a large JPEG
> scaled down to 100x100, the original JPEG will be passed into the PDF and then
> that will be scaled down when rendered (i.e. as much information in the original
> is preserved in the output).

'
Currently, the pdf gets 72’d when the engine renders.   Could it simply be adjusted for, say, 300 dpi resolution on output?



> 
>> I don’t need it to be the original, but rather visually indistinguishable.
> 
> Then that changes things slightly - particularly if your originals are scans
> which contain images rather than vectors... In this case, the render the PDF
> at a larger size and scale down approach should be able to give you want you
> want.


My originals are almost if not entirely text, lines, and boxes.

> 
>> As I think about it, I don’t think I’ve ever said *anything* nice
>> about pdf.  I’ve generally called it a bastardization
>> of postscript, but in this case, “castration” might be a better word .
>> . . (but then, when talking about cars,
>> I refer to the period from the early 70s to the mid 90s as “the Great
>> Emasculation” . . .)
> 
> Heh - the main thing to remember about PDF is that it is designed to be a
> description of what a postscript interpreter would output before things
> get rasterized. The idea is that it is a flat sequence of things to render
> and thus doesn't require the 'overhead' of a full programming language VM
> to do so. Of course, whilst it is that, it has also become a rather complicated
> on-disk data structure.

That’s not making me dislike it less :)


>> My first attempt seemed to work, save for an approximately 25% size
>> reduction I can’t explain.  more below . . .
>> I get a graphic of the same size as the pdf started, but the image is
>> about 3/4 the original
>> size.  The rest is transparent area.
>> My screen density is 108.79, but livecode doesn’t know that at the
>> user code level, does it?
>> However, that reduction *is* similar to 72/108.79 .  .
> 
> Physical screen density is irrelevant here - the engine uses a fixed
> notion of 72dpi... The 3/4 reduction suggests something PDF side is actually
> using 96dpi (72/96 = 3/4)... Perhaps Monte could chime in and comment?
> 
> It might be you just have to adjust the zoom factor to scale up the PDF
> slightly more so it fills the rect you want.

I’m thinking that a variable density would be derivable here.

Just increasing the zoom seem likely to do it, though:  I start with a 612 wide pdf widget (8.5”), zoom it 
400%, and get a graphic 4x612 wide.  However, only the left and top 3/4 or so of the graphic is used,
With the rest being blank.  The right and bottom are transparent. 

On top of that, when I change the width back to 612, the resolution is apparently downscaled with it.