lines get cutoff in the printed version

[rl-utility-man]

I am trying to PDF Python code using Print 0.11.15 and VS Code 1.81/1.82.2 and lines get cut off, so the final words are not visible. I circled the issue in red on the screenshot. This happens in both Chrome and Edge and with a variety of word wrap settings in VS Code. PrintCode wraps these lines as expected.

I would like printing a document to capture all the words in the document by default, perhaps with UI or a setting to allow line truncation.

[PeterWone]

Given the way it's designed to work not to mention some changes I made to cope with similar problems with FORTRAN source, this shouldn't happen and it's a bit of a surprise. Fundamentally this is an HTML line-breaking problem, probably affected by CSS. Do me a favour and post sample source for a repro.

[PeterWone]

This is what happens on my system using the same versions of vscode and Print as you quoted.

The somewhat different syntax-colouring is probably due to my sample not being syntactically valid Python because it's a fragment typed in from your screen snap.

More importantly, as you can see wrapping is happening as expected. If you have access to other systems that have VS Code on them, check whether this is happening on those systems.

[rl-utility-man]

Thank you for the speedy response! I have seen this bug occur on more than one big file with lots of long lines. Finding a succinct test case took a while -- it's clearly not always happening. Here's a relatively succinct test case: that reproduces the problem and cuts off the comments at the top of the function. I can reproduce the problem on a clean profile with only the Print extension installed. The final line of the test case seems to be necessary to activate the bug.

def main(master_path):

    #this code puts the logs and environment details in the directory component of input_path; if input path ends in a directory name, 
    # it will be treated as a directory not the file; i.e. f"G:\directoryname" will be treated as a request to put output inside G:\directoryname
    #and not as a request to handle a file called "directoryname" in G:\
    #log file mode should be W or omitted to overwrite the log each time the program runs; and should be "a" if the program is meant to 
    #add log entries on each of a series of repeated runs -- "a" is appropriate for e.g. webscraping programs designed
    # to pick up where they left off and produce results cumulatively
    log = get_logger(master_path, __file__, __name__, logging.DEBUG, log_file_mode="w")

    for diversity_parameter_times_10 in range(max_div_weight*10+1):
        differentiation_weight = diversity_parameter_times_10/10
        #backing off to a weight of .999 rather than 1.0 allows the citation counts to act as a tiebreaker.
        (selection_vector,cites_score, citing_authors_score,weighted_score)=find_greedy_solution(authornet_dict,max_depth,differentiation_weight,production_possibility_file,noncore_vector_to_exclude,production_possibility_list,log)

[rl-utility-man]

[PeterWone]

thé final line is necessary to activate the bug

OK that tells me what's wrong. The clipping happens because the wrapping container width is larger than the clipping container width. This is the problem I alluded to that was reported in respect of Fortran.

In that case I solved it with some logic that adds HTML soft breaks (the <wbr> tag). Something about that last line is causing it to not get extra breaks.

So now I get to have the most fun you can have in programming: debugging a regular expression.

For languages that permit it, a manual workaround is to add whitespace after commas, parentheses etc which will give the HTML wrapping logic an opportunity to break the line.

[rl-utility-man]

Much appreciated! If a second set of eyes on the regular expression would be helpful, let me know.

[PeterWone]

Seems to work now. There will be a release shortly. Let me know whether it works for you. Here's the regex. We replace with $1<wbr> which lets wrapping break at that point. The intent of the expression is

Put a break after any closing bracket brace or parenthesis, equals sign, comma, semicolon or alphanumeric run, provided it isn't inside an html tag

I hate lookahead, it can be very expensive. In this case it's not likely to be crippling because the string is only one line of the code, but if you can do better, be my guest. A replacement function instead of the regex replace is perfectly acceptable.

/((?:(?:[A-Za-z0-9_]{40}|[\])},;=]))(?![^<>]*>))/g

and here's the string on which it operates

<span class="hljs-function"><span class="hljs-keyword">def</span> <span class="hljs-title">main</span>(<span class="hljs-params">master_path</span>):</span>

    <span class="hljs-comment">#this code puts the logs and environment details in the directory component of input_path; if input path ends in a directory name, </span>
    <span class="hljs-comment"># it will be treated as a directory not the file; i.e. f&quot;G:\directoryname&quot; will be treated as a request to put output inside G:\directoryname</span>
    <span class="hljs-comment">#and not as a request to handle a file called &quot;directoryname&quot; in G:\</span>
    <span class="hljs-comment">#log file mode should be W or omitted to overwrite the log each time the program runs; and should be &quot;a&quot; if the program is meant to </span>
    <span class="hljs-comment">#add log entries on each of a series of repeated runs -- &quot;a&quot; is appropriate for e.g. webscraping programs designed</span>
    <span class="hljs-comment"># to pick up where they left off and produce results cumulatively</span>
    log = get_logger(master_path, __file__, __name__, logging.DEBUG, log_file_mode=<span class="hljs-string">&quot;w&quot;</span>)

    <span class="hljs-keyword">for</span> diversity_parameter_times_10 <span class="hljs-keyword">in</span> <span class="hljs-built_in">range</span>(max_div_weight*<span class="hljs-number">10</span>+<span class="hljs-number">1</span>):
        differentiation_weight = diversity_parameter_times_10/<span class="hljs-number">10</span>
        <span class="hljs-comment">#backing off to a weight of .999 rather than 1.0 allows the citation counts to act as a tiebreaker.</span>
        (selection_vector,cites_score, citing_authors_score,weighted_score)=find_greedy_solution(authornet_dict,max_depth,differentiation_weight,production_possibility_file,noncore_vector_to_exclude,production_possibility_list,log)

[PeterWone]

@rl-utility-man the issue was auto-closed when I merged. Don't let that stop you from testing. If it's not right please open a new issue and refer to this one.

[rl-utility-man]

Many thanks! Wrapping of the full file that I pulled the problem from now looks reasonable. I will open a new issue if I find other files that lead to unexpected behavior!

[sba923]

Seems that v0.11.18 doesn't fold lines when printing this .bat file: CollectSyncLogs.zip

[PeterWone]

@sba923 good catch. As with the issue above this is addressed by inserting optional breaks through the generated HTML. In this case, before / and \. It can't be after them because that would tend break in the middle of things like /I.