M-Files REST API Download Issue: PDF Fonts Not Embedded Causing PostScript Error on Print

We are trying to set up an automated workflow using n8n to retrieve specific daily files from M-Files and send them to an IP-enabled printer before the start of a shift.

When using the M-Files REST API to download PDF files, the resulting files appear to be missing embedded fonts.

  • Attempting to print these downloaded PDFs results in a PostScript error on the printer.

  • The downloaded files open and display correctly on screen, but the printing fails.

  • We attempted to use third-party libraries/scripts to embed the fonts post-download, but this introduced new issues: Turkish characters (such as ş, ğ, İ, ö, ç) are printed as squares or incorrect, weird symbols.

Is there a specific flag, parameter, or header that needs to be included in the REST API download request to ensure the PDF is delivered with all fonts fully embedded?

Is this a known limitation of the M-Files REST API when serving PDF files, and if so, what is the recommended server-side workaround for automated document retrieval and printing?

M-Files Version M-Files (25.9.15198.5)

Parents
  • Do the files open and print correctly when accessed directly in the M-Files client? Downloading via the API doesn't alter the files, so I'm suspecting the issue is with the source files themselves.

  • When I download the m-files file from the web, still doesn't have embedded fonts. When using m-files on desktop and saving it as a PDF using m-print option, there's no problem. The file normally comes from an invoice and an ERP system. The problem is that some properties in the m-files attached to the invoice are overwritten on the PDF. We're only experiencing issues with that overwritten text.

  • It sounds like the source files may require adjustments to ensure they're printable. When you use the "Save as PDF" option in the desktop client, M-Files relies on a PDF printer driver, which seems to embed fonts based on your observations.

    You might want to reach out to your M-Files representative for help with this. There are quite a few variables and settings involved, so this forum isn't the best place to dig into the details. They'll be able to review your files and guide you through the right steps.

  • They respond like that:
    "

    Hello,

    You are accessing the document via the REST API. The document displays correctly in M-Files.

    Currently, we do not provide support for the REST API. How you translate the document depends on the operation you perform.

    Thank you,
    "
    We would be happy if you could help us with this matter.

  • Can you show the request you make to the M-Files REST API?

    In general the REST API simply streams the file down from the vault with no conversion at all.  If that's the case then the issue is not related to the REST API, but down to the specific files themselves.  This seems to be confirmed as if you access the file via the web you also get no embedded fonts.

    In the case where you download them and then "Save as PDF" your local computer is doing a conversion.  That conversion is doing something to the files to "fix" them.  That conversion is not done by M-Files at all, so I can't comment on exactly what happens there.

    If it is the source files (which is my assumption right now from what you've described) you would either have to fix the source files before they were added to M-Files, or to have some sort of automated process within M-Files to fix them before you downloaded them, or to fix them after they are downloaded.  Which you choose would depend upon the exact behaviour you're after.

    I don't have a lot of experience with embedded fonts in PDF files though, so I don't think I can guide you on exactly what steps would be best.

    I would take the REST API out of the equation for now and go back to your reseller.  If you can replicate the same behaviour using the standard Windows or web clients then the REST API is irrelevant.  If you fix the underlying issue with the files then I suspect accessing them via the REST API will then start working.

  • The request I'm using in the REST API is as follows:


    "curl -L -g '{{MFWSUrl}}/objects/{{ObjectType}}/{{ObjectID}}/{{ObjectVersion}}/files/{{FileID}}/content'"


    It's best to fix the file after downloading it from M-Files. The text section causing the problem is because properties in M-Files (such as responsible person) are overwritten in the invoice file from ERP. I've tried several libraries but haven't been able to resolve this issue. I recently used the "ghostscript" tool, but I didn't get the results I wanted.

  • I think you probably need expertise from someone who has done lots of PDF file manipulation before to guide you.  The fact that this is in M-Files seems largely separate from the issue you're highlighting.

    The issue seems to be that the PDF you have downloaded isn't formatted or structured or built in a way that can be correctly printed; some library (e.g. ghostscript, but I have no visibility for whether that has the ability to resolve this) is probably needed, I agree, probably to flatten the file somehow.

    I'm sorry.  There's nothing really that can be done at the M-Files side, as this is due to the actual file itself; M-Files is just the storage medium.

Reply
  • I think you probably need expertise from someone who has done lots of PDF file manipulation before to guide you.  The fact that this is in M-Files seems largely separate from the issue you're highlighting.

    The issue seems to be that the PDF you have downloaded isn't formatted or structured or built in a way that can be correctly printed; some library (e.g. ghostscript, but I have no visibility for whether that has the ability to resolve this) is probably needed, I agree, probably to flatten the file somehow.

    I'm sorry.  There's nothing really that can be done at the M-Files side, as this is due to the actual file itself; M-Files is just the storage medium.

Children
No Data