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@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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
