Failed to create PDF document.

[HamedFathi]

Hi,

I just updated to the latest version (v3.5.1.2) and "Save To PDF" does not work.

I just unchecked "Show Headers and Footers" and the others are in default mode.

[RickStrahl]

Can you do the following to check something for me? I think this is caused by a previous version's configuration values not getting updated correctly, so I'd like to check by looking in the configuration file to see what is stored there.

Go to Settings (Gear Icon in Control Bar or Tools | Settings) and click on Edit JSON. Then jump to the PdfOutputWindow section and capture what's there and paste it here... I suspect there's some value in there that's throwing this off.

Keep your editor (not MM) open and remove the PdfOutputGeneration section, then restart and print again and see if that works.

FWIW, I've tried bad values here myself but I can't make it fail, but the error message definitely points to some invalid value in the configuration (not due to your input on the form which look fine).

[RickStrahl]

I think this is caused by this situation:

• Old configuration (which includes null values)
• Show Headers and Footers off
• Print

Null values are not allowed in the new WebView DevTools APIs I'm running and I check for that but only the headers and footers values are updated only when Show Headers and Footers is checked. I think if you print once with headers, the values fix up and it'll work from then on as the new values save.

Definitely a bug - I need to fix this at the API settings level, not the input level.

Please confirm though if my assumption is correct here.

[RickStrahl]

FWIW, I've updated to v3.5.1.4 which fixes at the lower level and should avoid this problem (assuming that's what it is).

[HamedFathi]

As you asked:

  "PdfOutputWindow": {
    "PageSize": "A4",
    "Orientation": "Portrait",
    "DocumentBackgroundColor": "White",
    "HeaderText": "[title]",
    "FooterText": "",
    "ImageDpi": 300,
    "GenerateTableOfContents": false,
    "DisplayPdfAfterGeneration": true,
    "Margins": {
      "MarginLeft": 0.0,
      "MarginRight": 0.0,
      "MarginTop": 0.0,
      "MarginBottom": 0.0
    },
    "MeasurementType": "Inches",
    "PdfPreviewTheme": "Pdf Output"
  },

Keep your editor (not MM) open and remove the PdfOutputGeneration section, then restart and print again and see if that works.

Unfortunately, I did not find any PdfOutputGeneration maybe I did not get your point.

I think if you print once with headers, the values fix up and it'll work from then on as the new values save.

I have the issue with "Show Headers and Footers" too so I think that is not the root cause.

I've updated to v3.5.1.4 which fixes at the lower level and should avoid this problem.

If you upload it I can test it.

[RickStrahl]

Sorry meant the PdfOutputWindow section...

But that looks all good. I also tried different paper sizes.

The message relates to one of the PDF input values to the Chromium engine, but that all looks good.

Hmmm... I did have a bug here a while back related to serialization that would serialize the numbers in locale-specific format (ie. commas instead of periods for separators in number for european for example), but that was fixed and I switched to actual serialization.

[RickStrahl]

Updated.

[HamedFathi]

Setup is still v3.5.1.2

[RickStrahl]

Should be there:

[HamedFathi]

The title is OK your setup file is not!

[RickStrahl]

Sounds like the files are cached. Try using a Private session to download.

Uploads and the version file are synced with the upload going up first, so they should always be synced.

[HamedFathi]

@RickStrahl

Thanks for your quick action, the problem was solved with the new version.

[RickStrahl]

Thanks for helping track this down.

[HamedFathi]

Issue came back in latest version :(

[RickStrahl]

Hmm... so that's pretty weird because nothing was changed between these versions in that code.

Pretty sure I know what the issue is: The new DevTools PrintToPdf takes JSON input for the print API interface and the parameters are very finicky. For example it doesn't like null values - it has to be an empty string, and double values can't have more than 2 decimal places. I suspect the latter is causing the problem.

Is it possible that you're using different document sizes when it fails/works? Can you also try giving specific dimensions?

I've played with this on my end and it works every time. The only other thing (checking this out now) might be some weird locale specific issue. What locale are you running in?

[HamedFathi]

I installed MM on another machine, and it works, but I still get the same issue on my machine.

I changed all fields in the export Markdown to a PDF page but had the same issue.

the locale for me is English/US and nothing strange.

Does the application have a special logging mode to gather more info?

[HamedFathi]

@RickStrahl

OK, I found the issue, when I want to create a PDF file from an unsaved document directly this issue will appear but if I save it then the PDF creation works.

[RickStrahl]

Good catch!

[RickStrahl]

Fixed and updated in 3.5.2.3

This bug was caused by trying to generate the HTML to a file with the same name and folder as the base file. Untitlted doesn't have that.

Reverted this to generate to the standard Preview output folder and rendering just like the preview with a base path.

This actually fixes two problems:

• The Untitled bug you pointed out
• Permissions issues if the folder of the MD file is not writable

This particular issue is fixed.

In addition I ended up fixing a few more small issues related to output:

• Pdf Output Theme displaying bogus header/footer due to new Chromium feature enabled by new release
• Couple of parameter formatting issues cleaned up for consistency

[HamedFathi]

Yes, solved, well done!