everything is in the title
I have a pdf file stored in a database.
I know how to send it by email,
I would like to print it (on mac and windows, bonus if linux too)
I try to be plugin-free
i tried to put it in an htmlviewer, and use htmlviewer.print, but the print has a very bad resolution ?
on mac I think I can use applescript to send preview the order to print the file ?
but windows ?
thanks.
Under Window 10, you could send the file to Edge, which opens PDF files, and use Sendkeys to plug Ctrl-P in Edge.
MBS Xojo Plugins comes with examples to print.
On Mac using PDFKit and on Windows using DynaPDF classes.
I don’t want to generate pdf files, I already have some pdf’s and want only to print them from my app.
Michel’s and Christian’s response do this.
You don’t just “print” PDFs. For them to be printed you first need to open them somewhere that understands PDFs and then from there “print” using the platforms printing mechanisms.
Michel’s solution uses a separate program to open the PDF and print it, whereas on a mac Preview or declares could work. Christian’s solution opens the file internally using his plug-ins and then your program can send it to the printer.
Unless you can open the PDF somehow your only other option would be to send the PDF directly to the printer as raw data (some printers accept PDF just as they accept PostScript, HP/GL or PCL ), which is different and so unusual it wouldn’t be an obvious answer. I wouldn’t even consider this since it means replacing the print stack in your OS with your own, connecting and talking to printers directly.
still, manipulating pdf’s should be in xojo framework !
@Jean-Yves Pochez: nope. This is for specialised vendors only. PDF as language is waaayyyyy more complicated than Xojo ever will be. Not even DynaPDF is doing what I want from a PDF plugin.
a canvas export and import as pdf would be completely transparent to most users, and enough powerful.
don’t need the full pdf language support.
They still have troubles with RTF, so for pdf
I love me some RTF (I use Ted extensively, especially in automations, where I built a whole invoicing system based on it) but at this stage I have to believe RTF support in Xojo is mostly legacy and won’t ever be improved.
I don’t personally use it much from within Xojo, so I may be wrong and it’s been improved continuously for two decades, but it would be a (good) surprise if that’s the case.
Whereas a discussion about PDF support in Xojo is worthwhile (I think hooks to the system viewers and PDF generation, where available, are not a crazy proposition) the reality is that it isn’t supported today, so it’s moot asking for it to work. The options are the same: Handle it through a plug-in, handle through system calls or handle through third-party software.
would prefer RTFD instead of RTF …
Doesn’t make a difference, in this context, since neither is properly supported. But RTFD is even less compatible and even less supported, as it’s really a bundle (a directory of files) and by extension less compatible. RTFD is not really a file format but a directory format (in reality an RTF with external objects embedded).
RTFD has all the shortcomings of RTF, but with the added caveat that it only works in NeXT-derived OSes.
for the records,
on mac and linux :
lp pdfFolderItem.ShellPathdoes the job.
[quote=406097:@Jean-Yves Pochez]for the records,
on mac and linux :
lp pdfFolderItem.ShellPathdoes the job.[/quote]
Yes, this uses an OS utility to send to the default printer using CUPS conversions. The OS opens the PDF and converts it for the printer’s preferred language. It’s equivalent to using AppleScript in that respect.
Unix and macOS use CUPS functionality (CUPS is Apple’s) but there’s no built-in equivalent for Windows (that I know of). In mac and linux behind the scenes you’re taking advantage of CUPS and the ghostscript or cocoa’s PDF routines to convert to PCL or whatever the printer supports. All of this is not built into windows.
Keep in mind you can’t use this for the Mac App Store.
what’s the reason for the this ?
It might be relevant to some people? It’s also a great red-flag for “this is really hacky” and I keep an eye out for those (they’re frequently non-solutions for me).
I just want to know why apple refuses using such shell call ?
are all xojo shell calls forbiden in the mac app store ?
I’m completely ok that Eduardo wrote it !!!
Ah, I get you now 
Sorry for the sass.
Apple rejects Xojo apps that use Shell functions.
(speculation:) It can lead to really unsafe things, like apps that attempt to unsandbox themselves at launch.
[quote=406123:@Tim Parnell]Ah, I get you now Sorry for the sass.
Apple rejects Xojo apps that use Shell functions.
(speculation:) It can lead to really unsafe things, like apps that attempt to unsandbox themselves at launch.[/quote]
I stopped sending to the store because of this. The usage of helper apps as such was not forbidden, but running anything under a shell is a no-no, if I recall correctly.
Helper apps needed to be launched through a special launch process instead which at the time I decided was too much effort.
EDIT: Found the thread where Michel explains how it works for him: https://forum.xojo.com/34755-mas-app-with-helper-app/0
and then https://forum.xojo.com/12479-helper-apps-and-the-sandbox/0