|
|
line wider = bad action of tab.png (28,732 bytes) |
|
|
|
|
|
I uploaded 2 screen captures. This happens after i set a character size twice bigger for page number than for the left text. - with too wide frame : the linenumber goes far too far right, considering the position of the right align tab in the ruler. - with normal size frame : right align tab does not show anymore in ruler, and left text has collapsed. size of page number is 22 here. |
|
|
AMOF the behaviour is weird. Editing the text with a right tab has really unpredictable effects like the image shows, but some other effects too. I upload a self documented SLA. tabs are between > and < chars. "Right tab 2 line jumps errors.sla" : A linebreak is "randomly" inserted in the string after the tab. Sometimes disappear when editing the text, sometime comes back, in a non-consistant way. |
|
|
|
|
|
right tab line break error.png (90,246 bytes) |
|
|
It looks like these problems arise when the right tab is "too close" to the right border of the frame. I upload SLA file and png image producing the "line collapsed" bug when one of the letter behing the tab is larger than others. |
|
|
right tab line collapsed error.png (59,534 bytes) |
|
|
|
|
|
Same with 1.4.2 Align right tab collapses all text on the left before the tab. |
|
|
scribus_tab_bug.png (30,256 bytes) |
|
|
I uploaded another screencast due to an "align right" issue reported on irc. The issue is only on first line. The reporter says : "The contents were made with the "generate table of contents" tool. I tried resetting manual character formatting, and also removing the line and re-typing it manually. There are some very weird dependencies with the content of the first line. If I change the initial P into an S, the problem disappears. Adding some other letter in front also makes it disappear, but punctuation does not. Since it only occurs in the first line, I was able to work around it by adding an empty line to the beginning of the frame and moving it up by the corresponding amount. It only occurs on the first line, and only if the last character is 0, 2, 3, 6, 8 or 9 (didn't test anything but numbers). Only specific fonts as well, but there's more than one font that exhibits this. As an update to that, the buggy number doesn't actually need to be the last character, it's enough that it occurs anywhere in the right part. So strings like a3a will also trigger the bug. " |
|
|
I appararently ran into the same problem and found this open bug. I first encountered it using the font League Gothic, but it seems to happen with certain others as well (e.g. Arial). I can confirm that the problem only occurs when one of the above mentioned numbers appear, and only on the first line. The problem does not only exist for a right aligned but also for a center aligned tab. |
|
|
To me, this is a really annoying bug because it makes formatting running headers and footers very tedious, having to insert enough hard spaces between words to make the text readable, and then whenever the bug is fixed, having to go back and take the spaces out of each document. I wish it could be bumped to a higher priority. |
|
|
i think, this should be classified as a bug, not as a feature! |
|
|
0008445 and 0012442 are related to align right tabs too |
|
|
marked as 'bug' from feature + bumped to 1.5.1. Closing duplicate of this bug |
|
|
0013372 brings a new SLA example with image. |
|
|
William, seems 0013372 is a duplicate of this ticket. |
|
|
I am trying to look to this issue I found the all text layout behaviours compressed in one function contain more than 2000 line and that really very bad code management. I hope the designer of the code break this function in many small functions. In our situation there are 2 main problems - first one : shrinking the text while the frame resizing - second problem: when you make the frame bigger the position of the text does not change to most right these problems happen only when you use the special char "TAB" so my proposal to solve this issue is finding the piece of code that check if entered char is tap or expanding char and add new assign for shrinking and position values I will try to solve this issue but the big problem is understanding what the programmer try to show in pagitem_textframe::layout >>>> very inconvenience function I put proposal to discus if I am correct and if not can you explain what wrong regard dawood |
|
|
If you come up with patches, I can test them. I agree with you about PageItem_TextFrame::layout() It is too long, and it has repetitive code that could be factored out. Also, it has a lot of tests for special cases, more than a normal Scribus user could memorize, which is probably detrimental to Scribus usability. I don't know if the Scribus project has regression tests, but I think that it would be impossible to make major changes to PageItem_TextFrame::layout() without a representative set of Scribus documents to use for regression testing. I had Scribus 1.4 documents that didn't preserve their formatting in Scribus 1.5, and I tracked it down to a change in PageItem_TextFrame::layout(), but it turned out that 1.5 implemented something that 1.4 ignored. http://bugs.scribus.net/view.php?id=12636 When I looked at the code, I added a way to add debugging. Those patches have been sitting around for over a year, so they probably won't be accepted and might have some bit rot, but they might still be useful, especially the changes to scdebug.h. http://bugs.scribus.net/view.php?id=12650 Regards, William |
|
|
PageItem_TextFrame::layout : in that heavy chunk of code, if you understand some set of codelines that uses a clearly defined context to perform a clearly defined action, then you could usefully create a dedicated function for that code. If you manage to create enough of such higher level function, it will be more easy to manage, debug and improve the code. |
|
|
I rise a comment to discuss the way to solve the issue of tab I will not change the function layout because i will not understand it ever ^_^ please if anyone have idea to share about tabs and shrinking share it. |
|
|
I have an example in the duplicate entry http://bugs.scribus.net/view.php?id=13372 with an overwrite that goes away if I remove a <tab/> from the SLA. If I had the time to look into it, I would start with the SLA that I posted in that report and make a second copy that is identical except for removing one of the <tab/> items that provokes the overwrite. Then I would add debug code to the layout code and compare the output from the two files. The first difference in the debug output from the good and bad SLAs should indicate where the layout is going wrong. It might take a few iterations of adding debug code and checking the differences in the debug output to pin down the line of code that causes the problem. You would need to understand the code only enough to have an idea where to add the debug code and what to print. Since it happens in both Scribus 1.4 and 1.5, it probably isn't worth looking at recent changes, but if you could find an even older version of Scribus where the tabs work, you could do a "git bisect" or "svn-bisect" to find the commit that caused the problem. Scribus has under 32K revisions, so bisection would take at most 15 steps, provided that you could find an old version of Scribus that does not have the tab problem and that is still buildable from source. |
|
|
Thank you all Who reply for me I divide the problem to 3 tasks: Task 1: text after tab. Task 2: text before tab. Task 3: align to right. I fix task 1 and now in task 2 I found out the tab has fixed size and it depend on the width of the frame so when you maximize the frame the text will be fine but when you minimize the frame it will continue to compress the text before the tab until the width of frame became as same as size of tab then the tab will goes to the next line and every thing will be fine. so I need to know if the behaviour of tab is good or it need to be change. Two options on front of me : 1- make the tab shrinking to a limit and then it goes to next line 2- make the tab goes directly to next line if the width of the frame does not fit for it please confirm for the best idea to start working for it. |
|
|
Just one comment to add The problem does not depend on the aligment. Aligment is another problem, but the main problem is how scribus deal with TAB |
|
|
as for me i dont understand the 2 options you propose. I think you should describe the situation you are tackling = an example of the tab position and exact definition and the text and the exact size of the frame. Maybe you could also propose a drawing with the various situations (bugy situation as is now, option 1, option 2). Maybe also William will understand and answer you better than i do. |
|
|
Mr JLuc I assume you understand what tab mean >>>> tab is an expanding blank the right behaviour for it is to shrink according to the content of line or stay in the default size. for example the tab in MVS is 4 spaces by default but it depend on the previous. for example: this is(------tab----------)first line. this is a wrong(--tab--)line this two lines have tab but the tab in the next line is shrinking to organize the text. this is the basic idea of the tab now in our problem the tab have text before and text after. The text after I solved its problem easily but the text before I just have confused because what is happening it shrink the (text before the tab) instead of shrink the tab This happens only when the frame does not fit to the text before the tab and the tab the right behaviour in my opinion is when the text does not fit in the width of the frame its go in next line as any char but I have to ask if this is what the developers need or they want the tab shrinking a little bet and then goes to the next line. that because they want the tab shrinking but instead some thing goes wrong and let the text shrinking I hope I clarify my point completely |
|
|
In the 2 lines that I show the the behaviour of the tab I adjust the end of tab but I think it will not be clear so I will draw it later and I will upload it here |
|
|
i'm sorry it takes long to understand but, well, that's how it is sometime when 2 non-english native speakers meet ! Now i dont understand how you use the word 'fit'. What does it mean to you when you say "the frame does not fit to the text" ? I could maybe understand it means that the frame is bigger than the text, but it doenst make much sense so can you explain ? And specifically what do you mean when you say "the frame does not fit to the text before the tab and the tab" ? etc |
|
|
I have to record Screencast to show you I will try to record as soon as i can |
|
|
https://drive.google.com/open?id=0B2zhep1TjhN_MWN1WDVkdk1oRnM look to tab position and text before it, the tab will push the text and shrink it until the width of tab became close to frame width and then the tab will goes down and every thing will became ok i am discussing the issue of tab now and ignoring the alignment for now |
|
|
Dawood, your google drive link requires permission to access. Can you open it up so that's not required? Or perhaps use a different service...? |
|
|
Yes dawood, i know that bugy behaviour. If you ask "what is the correct" behaviour, then my answer is : look in a Open Office or Libre Office. You can recreate the same situation and see how it behaves. oK ? |
|
|
sorry kunda,, I change the sitting you can see it now ok jluc i will do as liberoffice if I can :( only I get confused when I read the title of issue and I want to show that the main problem is (not) alignment, |
|
|
I am sorry to disturb you but I really need to understand this issue again I get confused when I produce the issue I modify the code slightly and I try to open the old sla file that jluc upload and it had another problem when I maximize the frame so I will upload small patch and I need someone reproduce the problem and record the screen what will happen to understand the issue come from the code or another dependency. |
|
|
Thats fine dawood. Since your work might have global effects on other situations with tabs, i recommend that you prepare and upload a no-regression-checks.sla document with a wide set of paragraphs and frames and tabs situations, where you and we can check that your patch or patches dont introduce regressions. Could you prepare and upload this no-regression-check.sla along with the corresponding produced reference PDF ? |
|
|
because I am not an expert in using scribus I get confused in producing the issue so I explain what I know in the sla file I notice that the problems comes out only with some formats so I am asking what is exactly steps that you are doing to produce that sla file that you upload in the past |
|
|
|
|
|
OK. I updated the no-regression-test.sla in adding the View > Display invisible glyphs option. 3 remarks including 1 answer : 1) none of the sample produces the error. You could add one or 2 sample with errors so as to both check no-regression AND test efficiency of future patches 2) none of the tested situations use paragraph styles. Tab positions are only default positions. But in scribus, tabs position can also be defined in the paragraph style. Of course, your patch should fix the issue in all situations : default tab positions and paragraph styles defined positions. And your no-regression-cheks.sla should ensure there is no regression also with paragraph style defined tabs. As a consequence, it would be good to add a 2nd page of example with tabs paragraphs that use styles that have defined tab positions. And of course, you could also include some buggy paragraphs in this 2nd page. 3) It could be that the answer to your "what steps produce the issue" is : defining tab positions in the paragraph styles. Look at the paragraph style of each the buggy paragraphs that have been uploaded and see where the tabs are positionned and what sort of tabs it is etc. so you can reproduce... and fix. |
|
|
4) dont use "no style" paragraphs because its more ambiguous how scribus deals with them and we need to be 100% sure of what is expected when debuging such an issue. Instead, use "Default paragraph styles". |
|
|
hello jluc sorry that was not a patch I am only try to discover from where the problems comes now it is clear that the bug happen because of many things>>> so I will come back for this issue at the end of this week |
|
|
have you found out something ? |
|
|
Jluc I am sorry for unconvince. I am so buzy this days but I promise you as soon as I can I will come back for this issue |
|
|
Same today, with scribusboxes. |
|
|
Example2.jpg (162,511 bytes) |
|
|
uploaded another example of this bug from a dupe (0012442) |
|
|
As of today CTL appimage, it seems align right tabs are buggy : they seem totaly ignored. Testing uploaded "right tab collapsed error.sla" |
- Anonymous
