search

1080linebooks / sigil

Automatically exported from code.google.com/p/sigil
GNU General Public License v3.0
0 stars 0 forks source link

Disorder of content files in 040-beta-3 #830

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. I'm replacing "<h3" with "<hr class="sigilChapterBreak" /><h3"
2. I'm choosing "Split on SGF Chapter marker (F6)"
3. The new files are generated at the end, not after the choosen file i did the 
split. The content is now not in the correct order.
...

What is the expected output? What do you see instead?

The new files should be inserted after the file where i did the split, not at 
the end

What version of the product are you using? On what operating system?

0.4.0. beta 3 Win XP 32

Original issue reported on code.google.com by fi...@gmx.net on 31 Mar 2011 at 2:15

GoogleCodeExporter commented 9 years ago 
This was actually the way it worked in 0.3.4, but I agree, the new splits 
should come after the original file.

Original comment by Strahinja.Markovic@gmail.com on 1 Apr 2011 at 12:45

GoogleCodeExporter commented 9 years ago

Original comment by Strahinja.Markovic@gmail.com on 1 Apr 2011 at 1:10

GoogleCodeExporter commented 9 years ago 
I have an additional issue related to that, the last split on sgf markers 
revealed

section0010.html
section0012.html
section0011.html

the correct order is 10 11 12

Original comment by fi...@gmx.net on 2 Apr 2011 at 3:10

GoogleCodeExporter commented 9 years ago 
Happened again, section0011 is always in front of section0010 when splitting 
files

Original comment by fi...@gmx.net on 2 Apr 2011 at 5:31

GoogleCodeExporter commented 9 years ago 
Had a book with fewer chapter, after splitting i got

section0009
section0008
section0010

Original comment by fi...@gmx.net on 2 Apr 2011 at 7:16

GoogleCodeExporter commented 9 years ago 
The problem with wrong order after splitting is issue 828 (this issue and that 
issue are two different problems).

Original comment by Strahinja.Markovic@gmail.com on 21 Apr 2011 at 7:28

GoogleCodeExporter commented 9 years ago

Original comment by Strahinja.Markovic@gmail.com on 21 Jul 2011 at 9:43

GoogleCodeExporter commented 9 years ago 
This is the same problem as Issue 863 and 828. It's caused by a problem with a 
dirty cache, and has been fixed, along with a similar issue which causes files 
to lose position if there are spaces in the file name.

Original comment by CajK...@gmail.com on 2 Aug 2011 at 11:45

GoogleCodeExporter commented 9 years ago

Original comment by john@nachtimwald.com on 2 Aug 2011 at 10:11