Font resize alternative #305
Comments
|
I've located the line responsible for updating font size according to slider configuration. It is PrompterView.qml#110. Removing the final part of the equation, which goes My only concern is that setting the max to a fixed amount won't scale with 4K, 8k, and greater display resolution. I'm thinking the slider's max range should, perhaps, be adjusted taking into account either viewport width or display resolution width for the display the window is at. |
|
166 px (if the screen shot is correct) is passable for HD use. Is it feasable to have unlimited pixel values for text resizing? Using a combo menu like Writer instead of a slider as an alternative control?
|
|
Similar resolutions are often seen on more recent MacBook Pros, where people will combine a near 6k monitor with an SD extended display. Unlimited, there will always be a limit, but we have not reached it yet in production uses yet. Combobox would be too limiting, but we should be able to do direct text input. Implementing it would be a bit tricky because the slider sets a percentage and that is used to compute pixel size, not the other way around, so the pixel size would have to be used to compute a percentage and that value is what would actually be set internally. (Similar behaviors exist in other parts of the program, including: margin widths, editor offset and reading region placement.) |
|
If the max width multiplicative factor is too small, the max value becomes less than the the min value, making increasing the slider value result in a smaller font and decreasing it resulting in a larger font rather than the other way around. Also, scaling linearly results in the font sizes too small on the low end and too large on the high end, high enough to crash the program. I don't know if these crashes relate to the font being too large or there not being enough space to contain them. The reason doesn't matter because the user shouldn't be able to set a size that won't fit in the viewport. Max font size needs to be computed based on viewport width. Using screen size results in font sizes too large for the small viewport breaks editor placement. Setting an arbitrary maximum will also break this on small viewports (which affects SD screen resolutions). This means an equation that scales maximum font size is required. A function with a growth curvature that matches that of the current maximum font-sizes would match the expectations of users switching from one mode of resizing to the other because, if the functions match, there shouldn't be a visual jump in the editor or in the slider when the mode is switched. An interesting but normal behavior arises from this feature is that as the max size gets reduced, if the font size hits the updated maximum font size will shrink as a result, similar to how it happens with the current implementation. However increasing viewport width keeps the text at its shrunk size, as it is to be expected from this feature. |
|
Note to self: I had initially thought importing documents in Open Document Format as an alternative to this, but it looks like that isn't really a viable solution. There are too many factors to take into consideration, some of which need to be discarded and we can't control whether end users will make use of them, which would break their expectations while importing. On a standard ODF document, the following factors affect the horizontal space occupied by text:
On QPrompt, which uses HTML and removes all margins and padding, the following factors affect the horizontal space occupied by text:
With all of these things in mind, we would need to predict the space a font would occupy based on the various ODF properties and use that to compute a font percentage size that will guarantee the same space is occupied in QPrompt. Unfortunately this conversion cannot be done without some data loss. Paragraph properties, for example, are translated as margins and would be discarded by QPrompt's filters. For this to work users would need to not use certain features provided by their document editors. Also, font availability cannot be guaranteed when the document is opened on a different system. |
|
How is Writer able to resize text only using numerical pixel values? |
|
They use point values, not pixels. Resulting pixel values are computed after the fact. We use pixels because it's the way Qt was designed to handle fonts. LibreOffice, if I remember correctly, uses it's own graphics toolkit designed specifically for LibreOffice, tho Qt is used to provide the window frame to draw on. Qt's pixel values are funny because, when it comes to up-scaling, they're also treated as points, but for historical reasons they're still referred to as pixels... |
|
Would you say, once document import is fixed that if both apps are set to 100% that the imported html should be the same text size as the source document's app? |
|
No, that's the thing, I don't think there's a good way to guarantee that. That could only be done assuming some formatting features aren't used and that both source and destination OS have the same fonts available system-wide. |
|
But with the slider solution you should be able to set a font size and it will remain that size regardless of window size. |
|
How about the currently disabled right-click context menu? |
|
The font dialog from that menu was replaced a while back with one that doesn't allow changing the font-size. That was done because Qt's FontDialog didn't integrate well with QPrompt. As for the context being disabled, it was always programmed correctly. The issue you saw is a bug in present in a few Wayland implementations. It has it's own issue for tracking so, we can discuss that here: #296 |
|
Understoid |
|
Just so you know, since we've replaced Qt's font dialog with our own, we now have full control over it. I implemented it using Qt Widgets instead of Qt Quick, so it's a bit more more difficult to program, but we're free to change things. Here's the conversation from when that change took place: #25 (comment) |
|
+1 vote by @er3eck on the idea of entering font size numerically. |
|
Added ability to enter font size numerically by double clicking on font label to show a TextField to enter the exact font size. Pressing enter accepts the change. Pressing Esc or focusing on something else cancels it. This is a good alternative to the exact font size slider, because that would've required adding means for switching slider modes, which would've been loaded or confusing given there already is a button in use towards the left of the slider. |
As you can see, although both apps appear to have the same font size when Writer zoom 100%, and QPrompt at full screen 100% font size, both have different point sizes... When attempting to match point sizes under same conditions, this occurs... |
|
Mathematically speaking the numbers QPrompt shows are the correct number of pixels on screen. The issue here is points in LibreOffice don't equate pixels on screen despite the document being set to 100%. I suspect that might be due to points being based on page size and the page size resembling on screen the dimensions of physical paper. If you put a piece of paper on top of the screen and the screen's pixels per inch are truly what they report to be (this is often not the case anymore), there should be a 1 to 1 correspondence between the page on the screen and the page in your hand. So this is also not a bug in LibreOffice, it's a feature. The question then becomes, how should we match the points in LibreOffice to actual pixels on the screen? |
|
Qt can be used to gather the screen's physicalDotsPerInch and logicalDotsPerInch. So we should be able to do some math with those values to achieve the same point values in QPrompt. However, if 100% or the size of a point in QPrompt v2.0 is different to 100% or the size of a point in v1.x, this is going to throw a lot of people off. |
|
We could add a setting to select font units. The default unit could be pixels and the alternative unit would be points. It feels strange adding a points feature considering QPrompt has no support for printing. What about margins? A document's margins won't match the screen's, so maybe a point shouldn't be defined as the size of a point when printing. It could also be defined as a fraction of the distance between margins... |
In other words. The fonts would scale as the window is resized, but a user could set a virtual page size to A4, portrait, with 2 cm margins, and the size of a point would be adjusted to fit as many words on the screen as could fit in an A4 portrait page with 2 cm margins. |
|
I use the selection of different font sizes and fonts a lot... and when the reading distance between the teleprompter and the presenter is small, I always adjust the margins so that the text is more centered on the screen to avoid the "running eyes" effect... so, for me, the selection of different fonts, font size and margin adjustment are functional and important. |
|
I don't know if it's relevant to the discussion, depending on the screen resolution used the font size reference changes... example: I have two notebooks, one with a resolution of 1366x768 and the other 1920x1080... the same font size looks different on both screens. |
@er3eck It's relevant. Are you looking at the percentage or at the pixel size? QPrompt uses a percentage value, so that your prompter settings translate across displays of different resolutions. All measurements (but actual pixel size, provided in parenthesis) are relative to the viewport's width so you don't need to tweak things like speed or acceleration ratios yourself, which is a thing you have to do in most other software. |
In Writer (and Word) the viewable text size on screen is a combination of type pixel value and zoom %. This is beneficial for editing if you wish to see the entire page, zoom to width only or other options and changing type pixel value to determing how much text fits on a line. However only the type pixel value is used when printing or exporting to PDF.
Some clients prefer a 'wysiwyg' workflow whereby a document created with say, 1920px wide will show what they desire to be on each line of the prompt output (assuming similar margins of course) as a starting point for rehearsal and performances.
In QPrompt, this can become an unknown quantity when 'printing to screen' or saving to html files. In prompt mode (the analogy of printing or exporting to pdf here) both the pixel value and zoom % appear to be factored into the result, however when saving to html, it appears as if only the zoom % is used? Compounding this, the saved html file reflects the window size, so you get different font sizes for a specific zoom % if QPrompt is full screen or windowed. Clients occasionaly prefer a hard copy that matches the prompted script's layout for rehearsal and editing purposes.
For clients who may utilize a 1920px wide document template and type pixel value to 'pre-press' their script, this causes inconsistencies when importing .doc or .odt files into QPrompt as its zoom % appears to override the word processor's 100% zoom level, which is what the client would be using as a template when their app is set to full screen.
In my opinion, QPrompt may benefit from an option where only type pixel value is utilized and zoom is disabled. Adjusting only one slider or direct input of a numerical choice to change type pixel value (whether selected text or whole document) to more closely match the .doc and .odt file (subsituted fonts not withstanding) may be more intuitive.
The text was updated successfully, but these errors were encountered: