|
2008-11-21 20:52
|
|
|
|
I don't see what you mean, please be more precise. |
|
2008-11-21 21:42
|
scribus 1.png (152,503 bytes) |
|
2008-11-21 21:43
|
scribus 2.png (151,659 bytes) |
|
|
Sorry, I've attached 2 screenshots now, maybe it's better to look at them. The second one is after vertical resizing of the frame. The line where changes are most visible is underlined red. |
|
|
And what's the problem???? |
|
|
Expected behaviour (at least by me) would be that when all the text parameters as well as frame widht are not changed, text flow also remains unchaged. When I lay out long article, I get rid of any loose lines, and then eg. change layout of pictures, causing the text to move between columns, I usually get some loose lines again. |
|
|
That can't be necessarily expected as changing frame height may modify the number of consecutive hyphenation break due to text flowing in other column, and the max number of consecutive hyphenation break comes into play then. |
|
|
Ok, I checked it. I increased the the frame height so that all the text fits in the first column, the second is empty. There is the same loose line I showed on my screenshot. Then I created another frame, covering exactly the first column of the frame in question, and enabled "text flow around frame", so that all the text jumped from the first column to the second. The loose line disappeared. (hope I'm clear now) Besides this, I'm not sure, but it seems to me, that the number of consecutive hyphenation limit works regardless of whether the consecutive lines are in the same column or not (at least is is what I observed) - and it is proper behaviour in my opinion. |
|
|
>> it seems to me, that the number of consecutive hyphenation limit works regardless of whether the consecutive lines are in the same column or not (at least is is what I observed) - and it is proper behaviour in my opinion. Yep this is the current behavior. And in fact i just discussed it with other team member and we think this is not a proper behaviour. When eye move to next column, it doesn't care about the previous. |
|
|
I think it is not only a matter of an eye, but also of increased difficulty of reading, and in this respect it's not important if this is the same column or not. And of course such a change - regardless of any possible issues with columns width - would certainly cause the behavior that I described above. Which is really quite a pain when you prepare larger journal. So if you change hyphenation algorithm, please at least make it optional. |
|
|
>> I think it is not only a matter of an eye, but also of increased difficulty of reading, and in this respect it's not important if this is the same column or not. I don't think so. |
|
|
More testing shows that your issue is mostly related to the use of glyph extension + alignment. Additionally i've detected some very small precision errors related to calculations with reals, but these are the limits of computer technology and cannot be fixed. Consequently this is also a duplicate of 0005891/0007070. |
|
|
Closing as this is a side effect of 0005891/0007070 |
- Anonymous
