![]() |
#1 |
Addict
![]() Posts: 234
Karma: 40
Join Date: Apr 2010
Device: The Nook, iPad
|
Odd Paragraph Style behavior for text input
I am using version 0.7.43 to convert some of my old text files to epub and found some odd behavior of the paragraph style setting. In my old version of 0.7.28, there used to be on TXT Input tab a check box that says "Treat each line as a paragraph" and one that says "Process using markdown" and if my text file is like this:
///Table of Contents/// ## Sub Header One This is the first. This is the second. This is the third. ## Sub Header Two This is the first. This is the second. This is the third. the older version will convert the text to epub properly with linkable table of contents and the paragraphs are all formatted properly. With the new version 0.7.43, if I don't tick the box "Force use of auto-generate Table of Contents" and choose the Paragraph Style Single per the user manual, it will also convert the paragraphs properly. However if I tick "Force use of auto-generated table of contents" and set Level 1 Toc = "//h:h2" per my example, the converted epub does not have paragraphs at all, the whole chapter just becomes one huge paragraph even if I leave the Paragraphy Style as Single per usual manual. I had to use editor to add an extra blank line for each intended paragraph, i.e., to change my text to something like this: ///Table of Contents/// ## Sub Header One This is the first. This is the second. This is the third. Then still set the paragraph style to Single (which is odd, per user manual this should now be "block" instead) and the converted epub will have correct table of contents and correctly formatted paragraph. Can someone look at this odd behavior and let me know if it's my input text issue or a bug there in version 0.7.43? Many thanks. |
![]() |
![]() |
![]() |
#2 |
Wizard
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 1,337
Karma: 123455
Join Date: Apr 2009
Location: Malaysia
Device: PRS-650, iPhone
|
You're actually bringing a bunch of different topics together with the TOC vs. paragraph discussion. Best to keep focus on one issue at a time.
For starters - did Auto/Auto on the paragraph type and formatting not work in terms of file generation (forget about the TOC)? I think I can see a potential issue, please confirm if I'm right. You are basically using 'pseudo' markdown formatting - based on your example you're not using spacing between paragraphs. 'Official' markdown formatting requires a blank line between every paragraph. Basically markdown 'requires' block formatting. Putting a space between every paragraph will make it block formatting which is what you've discovered. It doesn't actually matter that you set the style to single, the fact of the matter is that the markdown engine gets called, and it requires block. I think the older rev of the input plugin let you combine the two, but the recent changes don't allow that. I can see an argument though for allowing 'single' style formatting and markdown text. It wouldn't be hard to modify text input to support that, especially since the plugin modifications make both configurable. Regarding the TOC, I'm not really sure what the problem was there... I didn't think auto-generated would make any difference for text input. |
![]() |
![]() |
Advert | |
|
![]() |
#3 |
Addict
![]() Posts: 234
Karma: 40
Join Date: Apr 2010
Device: The Nook, iPad
|
Thanks, ldolse.
So long has I have "///Table of Contents///" and "## Sub Header" in my text file, the Auto/Auto on the paragraph type does not work, neither does Single/Auto: all the intended paragraphs (the single line on the the text file) are becoming a huge block concatenated together; and even though I checked "Do not add detected chapters to the table of contents" on the Table of Contents tab, the linkable table of contents gets generated. I don't know anything about markdown, I got the example from someone else on this forum before and it worked perfectly on older versions which I think you are right, the older version was more lenient on this. Now you said basically markdown requires blocking formatting, it all starts to make sense. I was hoping I can reuse my old text file most of which has each chapter in one block and within each block/chapter every paragraph is on a single line - which is very easy to navigate at a glance in a text editor and which worked fine on old versions of Calibre, now I have to change each line to a block to make the markdown more "Official", the text file is not as easy to navigate now as at a glance, I cannot tell chapters from paragraphs on the text file. But I guess that's the way it should be (?). |
![]() |
![]() |
![]() |
#4 |
Wizard
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 1,337
Karma: 123455
Join Date: Apr 2009
Location: Malaysia
Device: PRS-650, iPhone
|
Don't worry - I was just trying to make sure I understood the problem. I'm reviewing a possible change to support your old workflow with another developer.
|
![]() |
![]() |
![]() |
#5 |
Addict
![]() Posts: 234
Karma: 40
Join Date: Apr 2010
Device: The Nook, iPad
|
Thanks, ldolse, I just used editor to add an extra line after each line (making it a block sort of), so now there are three blank lines at chapter breaks where there was one blank line previously. It looks a little odd on text editor, but works perfectly if I leave everything as default (auto/auto on paragraph tab), it generates linkable TOC properly also (although I did not check anything on TOC tab), everything seems working automatically and it's actually quite easy for dummy users like me. So hopefully this ease of use can be retained. To edit the content in an editor, it's a little bit not as readable as before as there are more blank lines, but I can live with that or remove that extra blank line using the same editor, but obviously it would still be nice if the old format can be supported.
|
![]() |
![]() |
Advert | |
|
![]() |
#6 |
Sigil & calibre developer
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 2,487
Karma: 1063785
Join Date: Jan 2009
Location: Florida, USA
Device: Nook STR
|
Adding back some semblance of the old behavior is a priority. ldolse and I are discussing the best approach.
|
![]() |
![]() |
![]() |
#7 |
Sigil & calibre developer
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Posts: 2,487
Karma: 1063785
Join Date: Jan 2009
Location: Florida, USA
Device: Nook STR
|
Changes have been added to trunk. You will see them in 0.7.45. Paragraph style to will be accounted for before formatting processing. So auto and auto will detect the paragraph type and change it to accommodate Markdown processing before being processed by Markdown. This will give you back the old behavior.
|
![]() |
![]() |
![]() |
#8 |
Addict
![]() Posts: 234
Karma: 40
Join Date: Apr 2010
Device: The Nook, iPad
|
Many thanks, user_none. Looking forward to testing it.
|
![]() |
![]() |
![]() |
#9 |
Addict
![]() Posts: 234
Karma: 40
Join Date: Apr 2010
Device: The Nook, iPad
|
Thanks, user_none and ldolse, I tested v0.7.45 with UTF-8 encoded Chinese text with everything left at default setting, the result looks great; and I think if Chinese text works so well, English text file should not be any problem. Good job and excellent work.
|
![]() |
![]() |
![]() |
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Odd startup behavior from a new K3 | bfollowell | Amazon Kindle | 18 | 12-28-2010 05:24 PM |
PRS-900 Odd behavior (battery?) | Penforhire | Sony Reader | 1 | 06-22-2010 03:03 PM |
CSS odd behavior with ADE/Sony Reader | AbominableDavid | Sigil | 10 | 03-26-2010 09:16 PM |
Classic Odd behavior with random speed increases. | Not_A_Crook | Barnes & Noble NOOK | 0 | 12-25-2009 11:38 PM |
Odd line/paragraph breaks in epub and FB2? | PKFFW | Calibre | 4 | 10-01-2009 07:49 AM |