|
|
ascension.png (234,948 bytes) |
|
|
I cannot reproduce this one here. |
|
|
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! |
|
|
I can reproduce it with current 1.7.0 svn version. |
|
|
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! |
- Anonymous
