@previous two posts
I don’t think anyone is being ‘dogmatic’ about it, least of all Jon. AFAIK he’s never outright said that printing won’t be included in Sublime. From his perspective I guess that inbuilt printing is a minority request, that printing is easily achieved and that there’s a raft of other things that are just higher on the priority pile.
In trying to understand his reasoning, my guess is that the payoff for implementing a multiplatform print facility just isn’t there in the author’s view, at least for now. It has to be written to work across all platform print systems and, done properly, should have a bunch of ‘expected’ features like pagination, optional colouring, font selection etc. etc… It’s not difficult programming, but such things can be surprisingly time consuming.
At the risk of tediously repeating myself, the workaround of using ExportHTML is actually beneficial over an in-built print function in many situations, at least for me. Browsers have all this built in across platforms, and since the code ends up rendered in markup it can be easily styled using CSS and rendered to the printed page exactly to taste. Inbuilt print facilties rarely sport such flexibility. User CSS can be created to unify print style for teams or companies. In the end, printing is just a couple of extra mouse clicks / keystrokes which could be further simplified with a plugin.
The above won’t quell those who’d love a built in print function but I’m sure the author is well aware of its lack. I doubt he’ll shift his priorities on this, since occasional complaints have been dripping in for the last x years. The fact is that the majority seem more than happy with the ExportHTML approach and those who have a specific need for advanced inbuilt printing should probably look elsewhere. I’d love someone hear a specific reason as to why ExportHTML is unsuitable beyond the (rather dogmatic) ‘it just should be built in’ argument.
