Preview and Editor do not line up after in-line images are displayed

[hinder90]

Note: This is touched upon in some other issues like 3005 but I wanted to describe the issue explicitly and suggest a fix.

Current behavior

When scrolling the preview or editor view, the other view follows the scrolling location after a short delay. This is the normal behavior of how markdown code and the preview are kept in alignment so the user can see how their code and result can be compared.

However, when image objects are defined in markdown code and are rendered in the preview in-line, the actual height of the image (# of pixels) is not accounted for when mapping the "scrolling sync" location in the editor.

Possible Cause

My hypothesis is that "scrolling sync" location shared by the preview and editor is calculated in the preview by calculating the heigh needed by each rendered object. However the size of rendered images is not included in this total. The result is that any markdown code follows the image in the preview will be scrolling behind the editor by exactly the iimage height as rendered in the preview.

This problem also appears to be cumulative so after three images the preview will be behind the MD code by the height of all three images. If you document has many images you will be so out of sync that it is impossible to compare code with rendered output.

Expected behavior

As with the normally rendered preview without images, the scrolling location of the preview should follow the markdown code that rendered it as accurately as possible. This is to allow the user to write markdown code and immediately see the rendered result.

If my hypothesis about how the scroll location of the markdown code vs preview is calculated in the preview by the height of the rendered preview elements, Boostnote needs to include the actual height (in pixels) of the inline image to define this "scrolling sync" location. This seems inefficient overall as a method, so I am proposing an alternative approach:

Solution Suggestion

Rather than calculating actual pixel size of preview lines and objects, use the (offset adjusted) line numbers as the reference of "scrolling sync". The point of reference line could be arbitrarily set to be the top line of each window or perhaps the middle of the view box, but it could also be user adjusted (see below) dynamically by the user by a UI element. The reason why this approach could be better is because it prioritizes overall accuracy over local precision which assumes your object size calculations are all correct. (We can see that this is an example of where it isn't.) Calculating the scroll location each time when you scroll seems resource inefficient, assuming this is what actually happens.) If line-to-line mapping is offset so that it is an accurate count considering cases where lines in editor text don't translate to the number in preview.

For example, line count between editor and preview would have to be offset under the following circumstances:

• Line breaks visible in the editor that would otherwise be ignored in preview subtract from line count at that point and line number rounded down to that line.
• Any MD code lines that have multiple explicit line breaks that affect the total number of lines in the preview with line number rounded down to that line.
  (Rounding down is to align the lines by their start and so they are fully visible when the anchor line is the top of the view box.

By doing this, Boostnote never has to calculate the size of rendered objects ever. It just has to keep a single accurate line count. This makes testing significantly easier as well.

Addition Consideration

Finally, a visual element such as a a tall and narrow box that has a height if a line of markdown code text which indicates the anchor line between the editor and view box to easily match code to rendering. The anchor line could also be a highlighted as well though that might confuse the user into thinking that is where the cursor is. This location would be anchored to the view box as a single horizontal line across both the editor and preview where scrolling moves freely with line numbers matching at this single point. Either view could move smoothly to follow the other one being scrolled like it done now with that "magnetic" movement

There is a temptation to short cut this by making the anchor line for both views to just follow the location of where the cursor presently lis, however that would be problematic when the cursor is out-of-view as it would not be clear where lines match up. There is now obvious benefit of having the code and preview not locked in sync, but as user could turn this off if for some reason they need to see code and preview at the same time but at different points in the document. Therefore, the location of the cursor and the anchor line should be two separate locations as they aren't conceptually the same and need not be the same location for any other reason I can think of.

Bonus Feature

If we were to be more ambitious, this visual indicator of where the "scrolling sync" anchor line is location could also be a vertical slider which could be dragged up and down along the view divider so the user could decide where in the view the line anchor point is located. Rather than have yet another preference checkbox, just use this UI element to control where the anchor line is located as "a picture is worth a thousand words" when it comes to preference settings! You could just have a check box in preferences or in the header with the other tool shortcuts to enable/disable scroll sync.

TL;DR: By keeping line numbers in sync rather than calculating the theoretical height of the preview objects' pixel height to determine the scroll location in the preview view box you don't have to make sure all objects report pixel height is correct. This would also reduce the amount of recalculation needed when markdown code is edited and the views are scrolled.

How to Reproduce

To reproduce, simply include an image link in your markdown code which is then rendered in-line in the preview. You will see any markdown code that follows will be off-sync with the preview scrolling location by the height of every image's that precedes the line in the preview up to that point!

Environment

• Version : 0.14.0
• OS Version and name : MacOS 10.15.2

[Flexo013]

Thanks for your extensive description! This will definitely help with this issue being picked up by somebody.

[daiyam]

@hinder90 your issue may be corrected with #2405. If you have an example, I can test it.

[alexander-soare]

I'm not getting any alignment at all. Just started using boostnote so not sure if it's a settings thing. Could this be related to this issue or a fix in progress?

[daiyam]

@alexander-soare Do you have an example?

[alexander-soare]

@daiyam I'm not sure there's anything to give an example with. It's just that the functionality "preview scrolls with editor" does not exist for me. I only found out it should exist by finding this issue. It happens across all my notes, on desktop (Ubuntu 20) and on browser (Brave browser)

[daiyam]

@alexander-soare on browser, so it's an issue with the newer Boostnote... (https://github.com/BoostIO/BoostNote.next)

[alexander-soare]

The URL is https://note.boostio.co/app

…

On Mon, Nov 30, 2020 at 7:37 PM Baptiste Augrain ***@***.***> wrote: @alexander-soare <https://github.com/alexander-soare> on browser, so it's an issue with the newer Boostnote... ( https://github.com/BoostIO/BoostNote.next) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3441 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD6G5FJYDUUOU2SZFLDGQQLSSPYAXANCNFSM4KIMCMRQ> .

[daiyam]

Yep. The current repository is for the older app. The newer, which your are using, is at https://github.com/BoostIO/BoostNote.next 😉

[Flexo013]

Closing this issue as it seems to be resolved (tested in 0.16.1). If you do run into this issue again, then feel free to leave a comment here, and we'll reopen the issue.