|
|
critical layout bug.jpg (37,972 bytes) |
|
|
|
|
|
This issue never happens at the top of a frame, first or second column, when the frame is rectangle and not rotated. BUT it happens at the top of a second column, even when this top is perfectly horizontal, but when it has been altered using the shape palette. See new screenshot "shrunk on top of unevenly squared frame.jpg'. In this document, the Y of the 2 up right points are perfectly equal so line is perfectly horizontal. So it looks layout does not use same algorythm for a rectangular textframe topborder (ok) and for bottom borders of overlayedout rectangles (NOT ok) and for the horizontal top border of the text frame itself when it has been shape-edited (NOT ok). |
|
|
shrunk on top of unevenly squared frame.jpg (27,271 bytes) |
|
|
Confirmed on OSX 10.10.5 1.5.1svn r20696 |
|
|
fixed with CTL appimage |
|
|
Can't reproduce on 1.5.3svn r21652 @PeterBenedek please confirm |
|
|
I can't confirm! I can reproduce r21652 (Linux Mint 18; Qt 5.7) This is not CTL appimage! This is installed version. There's a difference? Upload: 0012862.png 0012862.png (17,909 bytes) |
|
|
0012862.gif (521,873 bytes) |
|
|
Still happens with today 1.5.4 svn :-( |
|
|
Does anybody got a workaround ? |
|
|
This crucial layout bug still happens with 1.5.5.svn version :-( Workaround in some cases is to break text frame into as many pieces as there are image breaks interupting the flow, and linking these pieces together so as to recover some (not all) editing abilities. That's very clumsy. |
|
|
afaik the workaround is easy: don't use 'maximum ascent' for the first line offset! i never use it. in fact, it is insane to calculate the vertical position of the text depending of the exact characters used in the first line. unfortunately this is the default setting (and there's no entry in the preferences to change it…) |
|
|
Hello utnik, i was full of hope when reading you had a workaround, but alas Changing the "ascent" doesnt fix the issue. Changing the "ascent" setting changes the layout. And it happens that in the specific layout at this moment, the issue doesnt show anymore. But when moving the introduing block slightly up or down, so as to adjust layout, then at some position, the issues comes back. I've tried all 4 ascent settings. |
|
|
sorry! – i need some more testing. |
|
|
i could not fix it by changing the first line ascent. but i could not reproduce it anymore, as soon i've switched from automatic line height to a fixed one. |
|
|
True ! It seems to happen only with automatic line height. I edit the title so as to reflect this. it makes a cool workaround. And i will ban any use of automatic line height in my documents ! |
|
|
might be related to 0009604 (i'm not sure about that…) it looks as scribus uses the height of the actually used characters for the first line after flowing around an object. (but it just calculates heights on a word-for-word base instead of the whole line of text.) |
- Anonymous
