Hello,
Thanks for the feedback. Expanding on the customization is something on our wishlist, but BC4's Input layout (left, right, center/ancestor) is locked.
As you found, you can pop out the Output pane with the small toolbar button, so it is free floating. While placing it in the middle and floating could work, if you placed it on the side, you could still keep horizontal orientation that flows from one side to the other, like an equation. Left -> Right -> Output (or output on the left side, if that's easier for review).
Merge with target between/adjacent to inputs instead of below? (no common ancestor)
Collapse
X
-
Merge with target between/adjacent to inputs instead of below? (no common ancestor)
Hello!
Is there a way to perform a text merge with the output/target file in the centre pane, i.e. instead of a common ancestor (which I don't have in this scenario)? Or in another (non-detached) vertical pane alongside the source content rather than below it?
If not, could I please request that it be considered as a possible feature in a future release?
The merge functionality is fine for me as-is, but I found the current pane layout options quite awkward with some non-source-code merges I was doing recently.
I'd possibly use such a layout for source code merges too as I'm not a fan of output-below even there, although it's much less of an issue than in this case.
Thanks in advance for your consideration!
Temporary Workaround
As a temporary workaround I detached the output pane, resized it and repositioned it so the content aligned with the source files, and plonked it over them roughly the middle. It was nice that it stayed on top when I focused and scrolled the source panes, but if I resized or repositioned the parent window I had to manually adjust the output pane again.
I'm lazy, so it would be brilliant if such a layout could be achieved without having to detach the output pane.
Additional context is that at 2K/4K there was enough screen real estate to get away with the detached output pane obscuring a large part of the source pane that sat underneath it. (However, at FullHD the 3-4 columns would only work if one could see their full widths, i.e. if they were all contained within the parent window.)
Background and Scenario Specifics
The background is that I was resolving issues with scanned text consisting mostly of numbers, which weren't recognised particularly reliably. After trying several OCR tools and algorithms I chose the two that were least bad, then merged their output for the final result.
What I found awkward with the output-below, source-code-merge layout was needing to constantly look up and down, between the source files in left and right of the top half of the screen, and the output/target in the lower half.
In this scenario I just wanted to look back and forth along each problem line. On the rare occasions where an OCR discrepancy triggered a line mismatch, I'd still only need to change my point of focus vertically by one or two lines instead of by half a screen for every discrepancy. It was a fairly even split between taking content from the left, taking content from the right, and some manual edits where neither OCR algorithm got it quite right.
Tags: None
Leave a comment: