View Issue Details

IDProjectCategoryView StatusLast Update
0017269ScribusTypographypublic2024-09-22 14:21
ReporterBN_Dev Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Platformx86_64OSLinux/macOSOS VersionAll
Product Version1.7.0.svn 
Summary0017269: Ascent not computed with variable text
DescriptionFont ascension with "Maximum Ascent" works predictably until a variable text mark is used. It appears as though the text in the mark is not read to determine the maximum ascension and the fallback of "Font Ascent" is used, even when the variable text does not contain any tall ascenders. I am aware that marks are an experimental feature and I have enabled these from the latest svn build.
Steps To Reproduce1. Create a text frame and enter some example text
2. Set the First Line Offset to "Maximum Ascent"
3. Note the text touches the top of the frame
4. Create a mark and with any text inside
5. Insert the mark in to the text frame
6. Note the text no longer touches the top of the frame
TagsNo tags attached.
PatchNo

Activities

BN_Dev

2024-09-14 18:31

reporter  

ascension.png (234,948 bytes)   
ascension.png (234,948 bytes)   

jghali

2024-09-16 14:58

administrator   ~0051350

I cannot reproduce this one here.

BN_Dev

2024-09-16 15:09

reporter   ~0051351

Would you be kind enough to send me a .sla that does not exhibit this problems so I can try and track it down with my current build. Many thanks!

nitramr

2024-09-16 20:51

developer   ~0051356

I can reproduce it with current 1.7.0 svn version.

BN_Dev

2024-09-22 14:21

reporter   ~0051382

I had a few hours today to start looking in to the core layout codebase and learning how everything is is working. I've tracked down the reason for this behavior to scribus/pageitem_textframe.cpp:1713

if (HasMark && !BulNumMode)
    realAsce = asce * scaleV + offset;

When the text frame is iterated and SpecialChars::OBJECT is encountered, it falls through various conditions and (although there seems a missing to check to ensure the mark type is MarkType.MARKVariableTextType) it trashes realAsce with the scaled height of the object regardless of what's inside it. It seems around here the glyps in the mark should be evaluated for the highest ascenders. I started playing with code to do this but I just seemed to be duplicating code nearby that was doing the same with the regular text frame content.

With the layout code being quite complex I'm treading carefully and wanting to check that I'm moving in the right direction. My feeling is rather than duplicating the code to check the ascenders in a string, that should be moved to a method so it can be called for regular text, variable text, and anything else etc., and the realAsce can be set to the qMax of whatever appears in the text frame. Because of the complexity of the layout I'm also unsure of the effects of doing this if the text frame content (including any non-variable text) is longer than width of the current column, whether a higher ascender that wraps *after* the first line should even be assessed/calculated. It seems like wasted compute to care?

Keen for any guidance and pointers for working on a patch on this. Many thanks!

Issue History

Date Modified Username Field Change
2024-09-14 18:31 BN_Dev New Issue
2024-09-14 18:31 BN_Dev File Added: ascension.png
2024-09-14 18:48 jghali Summary Ascension not computed with variable text => Ascent not computed with variable text
2024-09-16 14:58 jghali Note Added: 0051350
2024-09-16 15:09 BN_Dev Note Added: 0051351
2024-09-16 20:51 nitramr Note Added: 0051356
2024-09-22 14:21 BN_Dev Note Added: 0051382