|
|
|
|
|
Sure, I forgot. |
|
|
now fixed in footnotes_fix git branch See https://github.com/AlterScribus/contributors/tree/footnotes_fix for detailed logs logs : https://github.com/AlterScribus/contributors/compare/footnotes_fix?expand=1 |
|
|
I'll try to fix it anood |
|
|
hi, I noticed that this problem happened because of marks item does not update pages , it uses the previous pages , so I tried to use the getSectionPageNumberForPageIndex in the updateMarks function as you can see in the patch file, and I noticed that updateMarks does not call when section is updated, so I tried to call it in createIcon function . There is one problem , when I use textframe and marks (refrence to item ) in a page and I try to refer to another item in another page , it takes the first page number not the other page number . I don't know where I can update marks item pages , and which function is responsible for that! |
|
|
I'm afraid i dont understand. Maybe somebody else will. "marks item does not update pages" -> when should it update pages ? what pages ? What do you mean with "previous page" ? Why did you use createIcon specifically ????? As for "it takes the first page number not the other page number" : it's likely that you call the getSectionPageNumberForPageIndex function with the first page index instead of the other... « int page = destMark->OwnPage +getSectionPageNumberForPageIndex(mItem->OwnPage).toInt(); » is unpossible math adding first and other pages. I suggest changing it into « int page = getSectionPageNumberForPageIndex(destMark->OwnPage).toInt(); » but i havent tried yet. You have achieved something but more requires to be done. Marks are a powerfull feature and are worth your efforts :-) |
|
|
1- What do you mean with "previous page" ? I mean each mark saves page number , when pages are updated marks does not update their pages number . for example if I update page number offset to 5 each marks still saves the old page number not the new one! int page = mrk->getItemPtr()->OwnPage +1; return the old page number . I don't know from where I can update them. <hr/> 2-Why did you use createIcon specifically ????? I used backtrace for GDB to show what happened when Document Section is updated , and it shows that updateMarks() does not called after Changed page number offset, I tried to trace which functions called after Document Section changed, I found createIcon one of them . "marks item does not update pages" -> when should it update pages ? what pages ? see marks.sla I hope it's clear now :) |
|
|
OK. I think you should not call updateMarks in createIcon, because marks are not related to Icons, afaik, but call it at the same place in the code where createIcon is called, if that's a hint. + correct the issue you described "it takes the first page number not the other page number" |
|
|
int page = mrk->getItemPtr()->OwnPage +1; ^ it returns the page number which has mark? is this correct? |
|
|
I dont know. Have you tried ? What about getSectionPageNumberForPageIndex(destMark->OwnPage).toInt() ? |
|
|
Screenshot from 2015-11-03 14:05:20.png (156,449 bytes) |
|
|
Hello I have uploaded new patch and a screenshot that shows my patch works fine .It seems that updateMarks() doesn't called after the changes in section's page offset. So I called it in rebuildPages() and mark page's number always get page number from section's offset number. Regards, Anood Almuharbi |
|
|
Well done, it works fine ! Tested OK. [EDIT] : works fine only when page number of type 1.2.3... |
|
|
|
|
|
Unfortunately getSectionPageNumberForPageIndex is incorrect. Reviewing this with jluc |
|
|
Hmmm it's ok when page numbering uses numerals but its not ok when page numbering uses other styles as i,ii,iii or a,b,c or A,B,C etc toInt() is at fault since it converts all these to 0 |
|
|
this is another bug!, because Marks always display int value I'll try to fix that thanks cbradney and JLuc |
|
|
dont call toInt() so as to get i,ii,iii or a,b,c etc |
|
|
issue11812.patch (1,647 bytes) |
|
|
I have uploaded a new patch I think it will work fine :D thanks JLuc |
- Anonymous
