If the document contains specific characters, the fonts become smaller when printed
In some documents, I have noticed that certain strings cause the printed output to ignore my CSS font settings and make the text much smaller. However, I haven’t found what the exact pattern(s) causing this. But I assume it has to do with some parsing error. For example:
- "Buffalo_buffalo_Buffalo_buffalo_buffalo_buffalo_Buffalo" → odd number of underscores - "https://namu.wiki/w/%EB%B7%B0%ED%8B%B0%20%EC%9D%B8%EC%82%AC%EC%9D%B..." → special characters?
Some URLs with a lot of query parameters seem to cause the issue, but I’m unsure what the exact problem might be.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Brett on 20 Nov, 2024 01:43 PM
Could you please attach an actual document that displays this behavior, just so I can make sure I'm testing correctly?
Thanks,
Brett
On 20 Nov 2024, at 2:14, subscription.owl wrote:
2 Posted by subscription.ow... on 20 Nov, 2024 08:25 PM
For sure! The last line of lorem_ipsum.md has that url and if I comment it out, the document is about three pages for me. If I uncomment it, even thought a line was added, it shrinks.
Let me know if you can replicate it.
Support Staff 3 Posted by Brett on 20 Nov, 2024 08:57 PM
I'm not immediately able to replicate the issue. Could you go to Help->Report an Issue and copy the provided configuration data into this conversation for me?
4 Posted by subscription.ow... on 20 Nov, 2024 09:31 PM
Yup, here it is!
// Configuration (do not edit) Marked 2 1067 (Direct)
macOS Version: 15.1.1
additionalMathJaxConfig:
allowPageBreakInCode: YES
bookTxtIsLeanpub: NO
summaryMdIsGitBook: NO
codeIsPoetry: NO
codeCanWrap: YES
collapsibleHeadlines: NO
convertGithubCheckboxes: YES
convertGithubEmoji: YES
convertYAMLToMMD: NO
defaultMathJaxConfig: TeX-AMS-MML_HTMLorMML
defaultPreviewStyle: 100
defaultProcessor: MultiMarkdown
enableMiniMap: NO
excludeBlockQuotesFromCounts: NO
excludeFootnotesFromCounts: NO
excludeVerbatimFromCounts: NO
excludeCaptionsFromCounts: NO
folderPreviewExtensionsArray: md, markdown, txt, mdown, html, opml
githubNewlines: YES
h1IsPageBreak: NO
h2IsPageBreak: NO
hrIsPageBreak: NO
includeMathJax: NO
includeKatex: NO
limitTextWidth: NO
mathNumberEquations: NO
mathNumberEquationsSide: 0
mathNumberEquationsAMSOnly: NO
minimalJavaScript: NO
outlineModeExtensions:
permissionGranted: YES
printHeaderBottomLeft:
printHeaderBottomRight:
printHeaderFirstPage: YES
printFooterFirstPage: NO
printHeaderTopLeft: %filename
printHeaderTopRight: %date - %time (%page / %total)
processHTMLFiles: YES
removeMetadataForPreview: NO
removeYAMLHeaders: NO
scrollToEdit: YES
shouldDetectCritic: YES
shouldHighlightMarkupErrors: NO
shouldLoadCritic: NO
syntaxHighlight: YES
syntaxHighlightOnlyLang: NO
useCustomMarkdownProcessor: NO
customMarkdownProcessor: /opt/homebrew/Cellar/pandoc/3.5/bin/pandoc
useCustomPreprocessor: NO
customPreprocessor:
useFirstH1AsPrintTitle: YES
Support Staff 5 Posted by Brett on 20 Nov, 2024 10:05 PM
Is Pandoc enabled as a custom processor when you run into this issue?
On 20 Nov 2024, at 15:31, subscription.owl wrote:
6 Posted by subscription.ow... on 20 Nov, 2024 10:13 PM
Nope it isn't
Support Staff 7 Posted by Brett on 20 Nov, 2024 10:31 PM
Ok, well I'm afraid this is a bit of a mystery that's going to take a little more looking into. I'm not seeing the issue on my end at all, which makes it impossible to track down until I can replicate. Will do some digging this week and will let you know if I have more questions. Thanks for your patience!
-Brett
On 20 Nov 2024, at 16:13, subscription.owl wrote:
8 Posted by subscription.ow... on 20 Nov, 2024 10:35 PM
No problem — thanks for your help!
9 Posted by subscription.ow... on 30 Nov, 2024 07:20 PM
Hi Brett, hope you had a nice Thanksgiving — just wanted to follow up to ask if you were able to find what the issues is, thanks!
Support Staff 10 Posted by Brett on 30 Nov, 2024 08:48 PM
Unfortunately I still haven’t been able to replicate the issue, and thus have made no progress on tracking it down. I’ll keep fiddling with it.
Can you replicate this with other documents? Is there any consistency as to what type of string triggers the issue for you?
-Brett
On 30 Nov 2024, at 13:20, subscription.owl wrote:
11 Posted by subscription.ow... on 30 Nov, 2024 09:09 PM
Yes, I can replicate it with other documents. But it seems to be related to the inclusion of the string in the URL I shared above, not the URL itself: "%EB%B7%B0%ED%8B%B0%20%EC%9D%B8%EC%82%AC%EC%9D%B4%EB%93%9C."
Here's another example I found in the query string of a URL: "ie=UTF8&camp=1789&creative=9325&creativeASIN=1541645987&linkCode=as2&tag=theparexalif-20&linkId=19a16afda82169fcb032260b8ccbcb92."
I tried add parameters one by one from the beginning, and up until this part, it's fine: "ie=UTF8&camp=1789&creative=9325&creativeASIN=1541645987."
But once I add the next parameter ("ie=UTF8&camp=1789&creative=9325&creativeASIN=1541645987&linkCode=as2"), the size gets smaller. And when I add more, it shrinks further.
However, if I include only the parameters I initially thought were problematic (i.e., the latter part, "&linkCode=as2&tag=theparexalif-20&linkId=19a16afda82169fcb032260b8ccbcb92"), it doesn't cause any issue.
The same behavior applies to the first string. I tried removing characters from the end one by one (actually, one Unicode character at a time, such as "&9C"), and at a certain point, the size decreases, then it shrinks even further: "%EB%B7%B0%ED%8B%B0%20%EC%9D%B8%EC%82%AC%EC%9D%B4%EB%93%9C."
Support Staff 12 Posted by Brett on 30 Dec, 2024 06:57 PM
This is baffling, and I can't get the issue to happen for me. Have you discovered anything new in your experimentation?
13 Posted by subscription.ow... on 30 Dec, 2024 08:36 PM
I wasn't able to, but thanks for still keeping an eye on this. Is there a way to enable debug statements or logging so I can look into this myself as well? (I code for a living, so I should be able to use that to help.)
Support Staff 14 Posted by Brett on 30 Dec, 2024 09:21 PM
There's "debug" mode if you go to the bottom of Preferences->Advanced,
but it won't give you any useful information on this issue.
I'd be really curious what's going on in the DOM when the font size
shifts. Remind me, does the issue continue if you export HTML and open
it in Safari?
-Brett
On 30 Dec 2024, at 14:37, subscription.owl wrote:
15 Posted by subscription.ow... on 30 Dec, 2024 11:08 PM
Oh, interesting—it doesn't happen when I export it. They have the same CSS and the only element that's added is this:
https://namu.wiki/w/%EB%B7%B0%ED%8B%B0%20%EC%9D%B8%EC%82%AC%EC%9D%B
Maybe some special characters are breaking the HTML when it's rendered inside the app...?
Support Staff 16 Posted by Brett on 30 Dec, 2024 11:17 PM
There's a lot happening in the Marked preview window that isn't
happening in the browser, I was just hoping there was an off chance
you'd be able to export something that replicated the issue that I could
actually test with. It's really frustrating to see a clearly documented
issue and not be able to replicate it for debugging...
On 30 Dec 2024, at 17:09, subscription.owl wrote:
17 Posted by subscription.ow... on 30 Dec, 2024 11:41 PM
I see. Yeah, it's weird that it's not reproducible since I think the only three inputs that matter are 1) my preference 2) my CSS file 3) the markdown file I provided (and the switch is whether that URL exists or is commented out).
For what it's worth, I can only see this issue when I try to print it. So maybe something is happening during the printing process/dialog...?
Support Staff 18 Posted by Brett on 30 Dec, 2024 11:49 PM
Definitely something in the printing process itself. The web view Marked
uses is an old version of the one Safari uses, so it could be a bug in
that that Apple's since fixed, since they no longer support the version
Marked embeds (but a lot of Marked's functionality depends on features
that version has that the newer version doesn't). I'll keep looking at
it.
-Brett
On 30 Dec 2024, at 17:41, subscription.owl wrote:
19 Posted by subscription.ow... on 31 Dec, 2024 01:06 AM
Great, thank you. Just curious—if you try printing the
lorem_ipsum.mdwithcustom.cssusing the Mac printer dialog and "Save as PDF," one with the URL and one with it commented out, do they still appear the same?Support Staff 20 Posted by Brett on 31 Dec, 2024 06:27 PM
Yes, it's 1.5 pages long either way.
-Brett
On 30 Dec 2024, at 19:06, subscription.owl wrote:
21 Posted by subscription.ow... on 01 Jan, 2025 12:20 AM
I tried exporting both files to PDF, and they show identical font sizes.
It seems like it definitely has something to do with the print settings. I tried printing from my browser (tried both Chrome and Safari) after opening the exported HTML files, and they were the same. So I don't think it's browser-specific, but something happens right before the printer dialog is shown.
Any suggestions on debugging this?
Support Staff 22 Posted by Brett on 01 Jan, 2025 05:14 PM
Ok, that's interesting, and might help me narrow the issue down. Marked
does run a JavaScript routine right before the print dialog, so I'll
investigate that and see if _anything_ it does might get snagged on an
encoded URL. Does the issue show up in the print preview for you, or do
you actually have to print?
On 31 Dec 2024, at 18:20, subscription.owl wrote:
23 Posted by subscription.ow... on 01 Jan, 2025 05:49 PM
Great. The issue shows up in the print preview, so you wouldn't have to actually print.
Support Staff 24 Posted by Brett on 09 Jan, 2025 04:52 PM
I was finally able to replicate this! I turned off "Custom font size for export and print" in Style preferences, which was clearly overriding your stylesheet's font size. That was dumb of me not to realize that sooner.
Now that I can replicate the issue I can more easily start testing what might be affecting it. Sorry it took me so long to discover that.
Support Staff 25 Posted by Brett on 09 Jan, 2025 05:26 PM
OK, after some experimenting, I've noticed that it ONLY happens with your custom css. So now I need to figure out what in there might be affecting it. It looks like you've added !important statements already, which would have been my first suggestion, but it makes no sense that a URL encoded string would be affected by CSS. Are you seeing the same thing when you try printing with one of the built-in styles instead?
(I've also noted, at least in testing on my current machine, that half of my built-in styles are outputting blank PDFs. I have to assume that something is amiss on my new laptop as I would have expected to hear a lot more custom complaints about that by now. But that doesn't seem to affect your custom style.)
26 Posted by subscription.ow... on 11 Jan, 2025 09:27 PM
This is great! Thanks for locating the issue. The issue does not occur with built-in styles, so it must be something in my custom CSS that's causing it!
My suspicion was that the
@media printblock might be causing the issue, but after commenting it out, the font size still changes... Let me know if that's helpful and/or if there's any steps I should try on my end.