Font size logic for text drawing

[RFSH]

As part of #102, we're adding a text drawing tool. The following is how it works:

1. Clicking on the "text box " option should activate the text drawing mode.
2. Users can click anywhere on the page.
3. After clicking on the page, a blinking icon should appear, indicating that we're waiting for user input and a border box showing where the text will be added.
4. Given that we're drawing for a specific zoom level, should zoom be disabled?
5. As the user starts typing, we should show the typed text to the users.

During drawing,

• The text should have a default font size.
• Users should be able to change the font size.

In this issue, we want to explore the heuristics for the default font size and allow users to pick a meaningful font value. We should try to come up with uniform heuristics, so users pick font size values that they are familiar with (12px, 14px) and not the actual pixel size we'll show on the image (we would have to pick 1000px font size for images with multiple zoom levels).

Should the font size heuristics be absolute or relative to the zoom level? In both cases, we would have to factor in the image's size (width/height).

• Relative: On each zoom level, we have to make sure a typical 14px font size is displayed like other text types on the page.
  • This makes it simpler for users to pick the font size that makes sense for the zoom level when adding the text.
  • When users select a drawn text box, the default value of font size should be calculated for the current zoom level. But this means we must make the drawn text bigger/smaller if we change the zoom level during drawing. This would need to be clarified for users and be challenging to implement, so we would have to disable zoom during drawing.
• Absolute: The font size mapping is done based on the image's actual size and doesn't change by zoom level.
  • It would only be problematic with large images with multiple allowed zoom levels.
  • Users can zoom in or out during drawing, as the definition won't change.
  • The default value for the zoomed-out image might be too big, depending on how many zoom levels the image allows. OR the default value for the zoomed-in might be too small.

Based on this, we will try the "absolute" method first. We should see if we can develop a heuristic that makes sense for an image with 7 allowed zoom levels. And then see if the same heuristics make sense when we have only 2-3 zoom levels.

The following are the things that came up during the discussion:

• In a zoomed-all-the-way-out image, if the drawn font size of a text is too small, we should replace it with an icon instead. What if users select it? Should we zoom in on it?
• What about text thickness?

[nikhiilll]

For the font-size functionality we are going to try two different ways:

1. Absolute font-size
2. Relative font-size(takes zoom into account)

Absolute Font-size For this functionality, we need a mapping between the image font-size and the font-size outside the OpenSeadragon viewer application. This is needed because the pixel density of the images can be very high or low as compared to the rest of the web application. To achieve this we use the OpenSeadragon viewport container size and the dimensions of the image. The formula used to achieve this mapping is:

mappingRatio = max(imageWidth/containerWidth, imageHeight/containerHeight)

We then use this mapping ratio and multiply it by the user selected font-size to obtain the image font-size that would look like regular font-size. Other relative attributes use this font-size as well.

Relative Font-size The idea is to basically incorporate the zoom level, so that the font-size would look same as the web application at all the zoom levels. I'm trying a few approaches for this:

1. Take the current zoom level and the original zoom level to obtain the size of the image that is displayed. This requires some calculations using the original image size of the image. However, in this approach the zoom levels returned by the OpenSeadragon viewer are not absolute and seem to be calculated somwhat arbitrarily right now.
2. The other approach is to obtain the image size displayed directly from the OpenSeadragon library. However, no in-built functionality exists for this. So, I'm trying to find the dimensions of the image shown in the image viewport using the viewport dimensions, zoom level, original image, the curren position on the image and much more.

One of these two approaches should work. I'm currently working on this.

[nikhiilll]

Relative Font-size As mentioned in the previous comment, the second proposed method did not work. As we are using multi-image configuration for the OSD viewer application, the values returned by the OSD viewer functions is not accurate and reliable. I went ahead with the first method. In order to obtain the current zoom level, we are taking the current zoom level of the viewport object of the OSD viewer. We are also retrieving the default zoom level that we set while creating the OSD viewer object that is used at the start when the image is loaded. Using the default zoom and the current zoom we calculate a zoom ratio that provides us information about how zoomed-in or zoomed-out an image is. We then use this zoom ratio in the calculations of the font-size formula.

zoomRatio = defaultZoom/currentZoom
mappingRatio = max(imageWidth/containerWidth, imageHeight/containerHeight)
fontSize = currentFontSize * mappingRatio * zoomRatio

[RFSH]

We had a conversation about this, and the following is the summary of what we talked about:

• In this document, we looked at how different images behave with each implementation.
• The relative method is confusing as there's no reference point for the font definition. So if the user zooms in after drawing a text box, they cannot pick the same value to have the same size and have to find a different value that looks the same.
• The absolute method ensures that texts displayed on top of the fully zoomed-out image look the same as other text on the chaise page. To do so, we're using the width/height of the osd canvas in our scaling factor. But this means that the scaling factor is not "absolute" and changes as the user changes the browser size. This means,
  • We would have to update the displayed font size on the input as the user resizes the browser.
  • The same "14" font-size value picked when the browser is fullscreen will look different when we make the browser smaller.
  • We're currently only capturing the actual font size in the SVG. If later we add edit functionality, we would have to use the reversed scaling factor to find the font size that users see in the toolbar. In this case, the displayed font size might be different depending on the size of the osd canvas on load.
• Because of the issues mentioned above, we should come up with a scaling factor that stays the same throughout the usage of the viewer app. The scaling factor should most probably only be based on the image's width and height. One suggestion is to define the scaling factor based on the typical osd canvas size. So use the same formula, and instead of dynamic values for osd canvas, use something like 800x600.

The following are other improvements that came up as part of this discussion:

• We should offer the same font-size input as Google draw. So an input that has + and - buttons. And also a dropdown of commonly used font sizes.
• When the text is too small to the point that it becomes invisible, we should replace the text with an indicator indicating there's a text. We need to think more about the behavior. Should this show the text on hover? Or Should it zoom in so they can see the actual text instead?

[RFSH]

We've implemented the "absolute" method that is described above. We should discuss whether we need to make any changes to this logic.