Font size of printed RTF docs depends on DB window's size

DTPO 2.5.2 under 10.8.4 with Brother HL-2270 DW laser printer.

  1. Open a database in As Columns, As Split, or 3-pane view. Size the database’s window to fill the screen. (Alternatively, use ML’s full-screen mode.)

  2. Select or create a RTF document and ensure there is text in the document. Note the font size used in the document.

  3. Type Cmd-P. Note that the print preview renders the document in a minuscule font. Click the “Show details” button and under “Paper handling,” ensure that “Scale to fit paper size” is not checked (to ensure that this is not the cause of the problem).

  4. Print the document. It is printed in a minuscule font, not the font size used in the document.

  5. Resize the database’s window so that it is smaller and does not fill the screen.

  6. Type Cmd-P. Note that the print preview renders the document with a larger font, and the text fills more of the print preview’s page. Print the document. The document is printed with a larger font.

  7. Again resize the database’s window to make it smaller. Type Cmd-P. Note that the print preview renders the document with an even larger font that fills even more of the page. Print the document. The document is printed with an even larger font.

Surely, this behavior cannot be by design. My expectation is that the font size used in the document would be used in the printed document, regardless of the size of the database’s window.

The problem persists after quitting DTPO and starting it again, and after shutting down the computer and powering on again.

Anyone else seeing this?

Any particular reason that you are not using the latest release of DEVONthink (2.6.1 as of this writing)? If not, you might want to update DEVONthink and see if the problem persists.

Personally, I rarely print anything these days, so I don’t know if it has been, or still is, a problem.

I am not comfortable using 2.6.x because it “supports Mavericks” but Mavericks isn’t out yet, so there’s no way for me to validate that 2.6.x will not break when Mavericks is released in its final form. In addition, I will wait for a dot release of Mavericks with the first round of bug fixes before I upgrade to it. So, I consider 2.6.x a beta, since its target OS is still in beta, and so, 2.6.x is premature for my use.

Mavericks isn’t different from other OS X upgrades or updates, in the sense that Apple has been sending developers prerelease versions (in several stages prior to final release). That gives developers time to detect potential compatibility issues and avoid them.

So it isn’t as though the 2.6.1 release of DEVONthink is “beta”. It’s not. It works well with the versions of OS X in use by our customers, and should perform well when Mavericks is released in final form. That isn’t to say that additional maintenance releases will be done when Mavericks is released, and that may also be required when Mavericks is updated.

Thanks for the info.

Can you comment on the problem that I’m having?

Thanks.

I’m seeing the same thing, but it is not limited to DEVONthink. Pictured below is the print dialog of an RTFD document in TextEdit. Look how the number of pages changes depending on the size of the document window. I made the document window much smaller and the number of printed pages went from 16 to 42. So whatever the issue is, looks like it is a problem with how OS X print services is handling RTFD documents.

Thanks for checking with TextEdit. That’s exactly the problem. Here are my results with with a few different text editors using the procedure you illustrate:

App: problem occurs (Yes/No)?
DTPO 2.5.2: Yes
Bean 2.4.4: No
TextEdit 1.6 (Snow Leopard version running on 10.8.4), in either RTF or plain text mode: Yes
TextEdit 1.8 (10.8.4 version), in either RTF or plain text mode: No
Notational Velocity 2.0: No
Mail 6.5: Yes

I’m not sure what this reveals, if anything, since (as far as I suspect from common sense, not being a Mac app developer) each of these apps could use all, some, or none of the OS’s RTF framework.

Are you on 10.8.4?

Since Mail shows this weird behavior, I will send a bug report/comment to Apple. But, I hope that someone from DEVON could test and comment on this? I expect that a bug report from DEVON might stand a better chance of Apple paying attention.

Yes, so I the results I posted above is with TextEdit 1.8 (301).

Weird. I am on 10.8.4 using TE 1.8 (301) too, and the problem does not happen with TE on my computer.

If you have a moment and care to pursue it, could you test with an email?

Thanks for your input.

Curious, but I don’t see it with Mail here.

OK, it’s off to AppleCare I go, wish me luck.

Thanks for helping chase this down.

AppleCare observed that this behavior in Mail.app can be avoided by selecting “Keep the same apparent font size” in the printing options. Some subsequent experimenting with TextEdit 1.8 (301) shows that this behavior can be changed by checking and unchecking “Rewrap contents to fit page” in TE’s print options. Not surprisingly, AppleCare has no idea why this is occurring in DTPO, which does not have a similar option for printing, so I will open a ticket with DEVON.

This option IS available in DT.

If you set your print margins in the document then fit the window to your page size, you should get expected results. For example, setting the left margin to 8" and resizing the window to 8.5", I get the expected results in the print preview. Similarly, if I change the margin to 6" and the window to 6.5", I get proprtionally different results. Both of these are WITHOU rewrapping content.

PS: This is all from Apple’s frameworks.

Sorry, how is this done? As far as I can determine, the RTF editor does not have way to set the left margin. There are ways to set indentations, but this is not the same as a margin: text in table cells is changed to use these indentation settings, which makes for a lot of cleanup.