Open Snackhole opened 2 years ago
I've created a package, with reference to html_print.py
, that fixes this behavior. Attached is a zip file containing the package and the source code. It's pretty messy code since I had to work with the existing output of view.export_to_html
instead of being able to edit the way the export is created in the first place. I expect there are probably bugs I wasn't able to suss out and more efficient ways of implementing it, but I've verified it seems to work with .txt files well enough for my purposes.
Though this package solves my own problem for now, I do hope that this behavior is adopted in a future release.
Description of the bug
If
indent_subsequent_lines
is set totrue
(which is the default setting) and you print a plain text file with indented lines long enough to be wrapped, the subsequent wrapped lines are not indented as expected.Steps to reproduce
indent_subsequent_lines
is set totrue
.Expected behavior
The subsequent lines of the wrapped line should be indented to the same depth as the start of the line, as is displayed in ST itself due to the
indent_subsequent_lines
setting.Actual behavior
The subsequent lines are not wrapped.
Sublime Text build number
4125
Operating system & version
Windows 10 and Kubuntu 20.04 LTS
(Linux) Desktop environment and/or window manager
KDE
Additional information
It appears that the print function works by generating an HTML file and sending it to the browser to be printed; so to fix this, what would need to happen is that the generated HTML is altered to respect the
indent_subsequent_lines
setting.Currently, the print feature dumps the entire text of the file into a single
<div>
with inline CSS containingwhite-space: pre-wrap;
, and all line breaks replaced with<br>
. I suspect that, if it is agreed that this indentation behavior is a bug, the text would have to be split into multiple<div>
elements on a per-line basis, with the number of leading tabs and spaces counted, an appropriatech
value forpadding-left
set in the CSS for each element, and the leading and trailing whitespace stripped from the actual line, with only line breaks for empty lines being replaced with<br>
elements. (I assume the appropriatech
value for any given sequence of tabs and spaces could be determined using whatever code is used to render tabs and spaces in ST in the first place. I also assume the existing print code can remain in place for whenindent_subsequent_lines
is set tofalse
.)For example, take the following text:
ST currently generates the following HTML to print this text:
If printing respected
indent_subsequent_lines: true
, it might instead generate HTML like this:As a side note, since the font used is monospace, I believe the fact that
padding-left: 4ch
andtab-size: 4
refer to different characters to determine the rendered width shouldn't matter. Thech
unit refers to the width of0
, andtab-size
uses the width of the space character, but for a monospace font those are the same value anyway.OpenGL context information
No response