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

Mark Waddingham mark at livecode.com
Sat Sep 7 07:29:23 EDT 2019


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

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

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

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

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps




More information about the use-livecode mailing list