PDF from Server is strategically important

Idea created by CarstenLevin on May 26, 2016

Comment • 10

Active

Score29

+20 more

Summary

Creation of PDF without loosing any of the existing advanced functionality (like append to PDF)

From:

Server Script
- Thus also from "Perform Script on Server" Script Step
From WebDirect, possibly via "Perform Script on Server"

With a development UI supported way to write the new PDF directly to a specified container field.

Why this is important for me

We see WebDirect as a strategic enabler for our FileMaker development. And the generation of PDF's is maybe our major problem when considering deploying solutions via WD for new customers and when building modules for use with WD for existing solutions.

Business Cases

All new biz where it is an advantage not to have to install an application.

All business cases where the user will use his from different locations/platforms.

When generating complex PDF's taking a lot of data power from FileMaker Go solutions or from WD solutions used from Android, iOS etc.

When developing CWP (Custom Web Publishing) sites.

Yes, I could continue, but I hope this is enough.

Best regards to everybody

Carsten

ggt667 Jun 11, 2016 8:39 AM

Here is a proof of concept as discussed at dotfmp[x]Berlin 2016 that will work with all versions of FMS that has server side scripting with post execution of scripts http://wethecomputerabusersamongst.blogspot.com/2016/06/filemaker-fmxmlresult-to-latex.html

This way you will get lean PDFs, about half the size of those made using FileMaker. For 1 PDF this is irrelevant, but if you make a couple of 100 000s pr year, this will improve the user experience in improved bandwidth alone.

Actions

intex Jun 12, 2016 4:33 AM

at least partially a duplicate

PDF generation in runtimes and webdirect

Actions

CarstenLevin @ intex on Jun 12, 2016 12:43 PM

Hi index and ggt667 I know that there are many work-arounds, and we use a fair amount of them in different solutions.

But please, I hope you agree that we need the support for PDF in server and via WebDirect.

Best regards

Carsten

Actions

ggt667 @ CarstenLevin on Jan 3, 2018 10:56 AM

I don't agree or disagree, I always use native approaches.

Using LaTeX for this task will in this case be a unix/linux native component, and will operate freely as a separate unit in the system where it's installed; with as little overhead as possible.

Of course I agree that using FileMaker's layout tool will be quicker, easier and lazier. However I doubt it's the most efficient approach for a production environment, when counting clock cycles and planning bandwidth usage.

And for WebDirect; I'm not sure if it's a good thing at all, depends on how it will be implemented. Perhaps if FileMaker makes a tool that configures perfectly fine open source, it can make a solution that flies. I'm a bit hesitant the way FileMaker forked FX.php and turned it into a some what obfuscated phpFileMaker; probably to hide the similarities. What if they used the already existing project and just made a seemless integration? Half the job; double the satisfaction.

Actions

extremekiwi Oct 13, 2016 2:56 PM

Carsten... I'm surprised there has been so little feedback on this - you have nailed it with the business cases presented.

You raised this issue 26/05/16. So where is Filemaker on this?

Actions

ggt667 @ extremekiwi on Oct 14, 2016 12:27 AM

We all know the size of the PDFs produced by Filemaker, and the size does not matter if you make a couple of hundred PDFs, but if you are to make millions of PDFs the size of the Filemaker produced PDFs are too large. Let us hope that FileMaker makes an effort into reducing the size of each PDF if implemented on server.

Actions

CarstenLevin @ ggt667 on Jan 3, 2017 3:52 AM

Hi gggt667 do you refer til older versions 12-14.0v4 or later ... at least the new pdf engine improve regarding the size.

Actions

ggt667 @ CarstenLevin on Jan 3, 2017 4:24 AM

I have clients with solutions running FM5.5 - FM14, I have seen the newer ones are better, yet still contain extras. Only reason not moving to the FM14 to FM15 is the new licensing regime. Reason for not moving from FM5.5S is the lack of linux support for newer versions. As a matter of fact the uptime for the FM5.5S is about 10 years, it's not exposed to the web directly, only via VPN and XML RPC using FX.php from a FM6P

Actions

esaeberg Jan 3, 2018 10:45 AM

It's done since the version 16

Actions

ggt667 @ esaeberg on Jan 3, 2018 10:54 AM

Or 5.5 and up if you read the blog in my first comment.

Actions

10 Comments

ggt667 Jun 11, 2016 8:39 AM
Here is a proof of concept as discussed at dotfmp[x]Berlin 2016 that will work with all versions of FMS that has server side scripting with post execution of scripts http://wethecomputerabusersamongst.blogspot.com/2016/06/filemaker-fmxmlresult-to-latex.html

This way you will get lean PDFs, about half the size of those made using FileMaker. For 1 PDF this is irrelevant, but if you make a couple of 100 000s pr year, this will improve the user experience in improved bandwidth alone.
Like • Show 0 Likes0
Actions
intex Jun 12, 2016 4:33 AM
at least partially a duplicate

PDF generation in runtimes and webdirect
Like • Show 0 Likes0
Actions
CarstenLevin @ intex on Jun 12, 2016 12:43 PM
Hi index and ggt667 I know that there are many work-arounds, and we use a fair amount of them in different solutions.

But please, I hope you agree that we need the support for PDF in server and via WebDirect.

Best regards

Carsten
Like • Show 0 Likes0
Actions
ggt667 @ CarstenLevin on Jan 3, 2018 10:56 AM
I don't agree or disagree, I always use native approaches.

Using LaTeX for this task will in this case be a unix/linux native component, and will operate freely as a separate unit in the system where it's installed; with as little overhead as possible.

Of course I agree that using FileMaker's layout tool will be quicker, easier and lazier. However I doubt it's the most efficient approach for a production environment, when counting clock cycles and planning bandwidth usage.

And for WebDirect; I'm not sure if it's a good thing at all, depends on how it will be implemented. Perhaps if FileMaker makes a tool that configures perfectly fine open source, it can make a solution that flies. I'm a bit hesitant the way FileMaker forked FX.php and turned it into a some what obfuscated phpFileMaker; probably to hide the similarities. What if they used the already existing project and just made a seemless integration? Half the job; double the satisfaction.
Like • Show 0 Likes0
Actions
extremekiwi Oct 13, 2016 2:56 PM
Carsten... I'm surprised there has been so little feedback on this - you have nailed it with the business cases presented.

You raised this issue 26/05/16. So where is Filemaker on this?
Like • Show 1 Like1
Actions
ggt667 @ extremekiwi on Oct 14, 2016 12:27 AM
We all know the size of the PDFs produced by Filemaker, and the size does not matter if you make a couple of hundred PDFs, but if you are to make millions of PDFs the size of the Filemaker produced PDFs are too large. Let us hope that FileMaker makes an effort into reducing the size of each PDF if implemented on server.
Like • Show 0 Likes0
Actions
CarstenLevin @ ggt667 on Jan 3, 2017 3:52 AM
Hi gggt667 do you refer til older versions 12-14.0v4 or later ... at least the new pdf engine improve regarding the size.
Like • Show 0 Likes0
Actions
ggt667 @ CarstenLevin on Jan 3, 2017 4:24 AM
I have clients with solutions running FM5.5 - FM14, I have seen the newer ones are better, yet still contain extras. Only reason not moving to the FM14 to FM15 is the new licensing regime. Reason for not moving from FM5.5S is the lack of linux support for newer versions. As a matter of fact the uptime for the FM5.5S is about 10 years, it's not exposed to the web directly, only via VPN and XML RPC using FX.php from a FM6P
Like • Show 0 Likes0
Actions
esaeberg Jan 3, 2018 10:45 AM
It's done since the version 16
Like • Show 0 Likes0
Actions
ggt667 @ esaeberg on Jan 3, 2018 10:54 AM
Or 5.5 and up if you read the blog in my first comment.
Like • Show 0 Likes0
Actions

PDF from Server is strategically important

Related Content

Recommended Content

Incoming Links