[Editor Plugin] Diap's Editing Toolbag

[DiapDealer]

Glad you got it working.

Thanks for picking up my support slack @jackie_w.

[jackie_w]

Originally Posted by DiapDealer

Thanks for picking up my support slack @jackie_w.

You keep 'slacking' by developing useful new stuff and I'll keep answering straightforward questions. Seems like a good division of labour to me!

[sherman]

Hi DiapDealer

This looks to be an amazing plugin.

Have you thought of making an addition to replace paragraphs formed using break tags to those using paragraph tags? Would this fit into the theme of the plugin? Would you be interested in implementing such a feature if it did fit?

Example of what I mean:

Turn this:
...
This is a paragraph...<br />
<br />
This is another paragraph.<br />
<br />
... 

Into this:
<p>This is a paragraph...</p>
<p>This is another paragraph.</p>

Currently I use multiple fragile regex's, and hope I don't stuff it up...


Your thoughts?

[theducks]

Originally Posted by sherman

Hi DiapDealer

This looks to be an amazing plugin.

Have you thought of making an addition to replace paragraphs formed using break tags to those using paragraph tags? Would this fit into the theme of the plugin? Would you be interested in implementing such a feature if it did fit?

Example of what I mean:

Turn this:
...
This is a paragraph...<br />
<br />
This is another paragraph.<br />
<br />
... 

Into this:
<p>This is a paragraph...</p>
<p>This is another paragraph.</p>

Currently I use multiple fragile regex's, and hope I don't stuff it up...


Your thoughts?

IMHO Your fragile REGEX is probably a more robust REGEX because you tune it to your exact condition

<p> is simple

what if the first tag was a:
<div class="foo"> <span class="bar">
or
<p class="foo"> <span class="bar">

or the <br /> was inside another tag

<i>there she<br /> blows</i> (up )

[DiapDealer]

Originally Posted by sherman

Hi DiapDealer

This looks to be an amazing plugin.

Have you thought of making an addition to replace paragraphs formed using break tags to those using paragraph tags? Would this fit into the theme of the plugin? Would you be interested in implementing such a feature if it did fit?


Currently I use multiple fragile regex's, and hope I don't stuff it up...


Your thoughts?

Glad you like the plugin. But I'm afraid any attempt to automate such a process is going to leave one "hoping they didn't stuff it up."

First and foremost, I create tools that I need/want for my own use; and happily share them with others who may be looking for similar tools. But I'm afraid I long ago grew tired of trying to "fix" ebook code that was so bad its paragraphs weren't clearly delineated. Now I just discard that sort of soup and look (or wait) for something better with which to start. I still like to spend more time reading ebooks than I do working on them, after all.

I think calibre's line unwrapping feature (part of its conversion options) does as admirable a job as any at this sort of thing, but there's always going to be some guessing and hoping (and proofing and reproofing) going on.

[sherman]

Originally Posted by DiapDealer

Glad you like the plugin. But I'm afraid any attempt to automate such a process is going to leave one "hoping they didn't stuff it up."

First and foremost, I create tools that I need/want for my own use; and happily share them with others who may be looking for similar tools. But I'm afraid I long ago grew tired of trying to "fix" ebook code that was so bad its paragraphs weren't clearly delineated. Now I just discard that sort of soup and look (or wait) for something better with which to start. I still like to spend more time reading ebooks than I do working on them, after all.

I think calibre's line unwrapping feature (part of its conversion options) does as admirable a job as any at this sort of thing, but there's always going to be some guessing and hoping (and proofing and reproofing) going on.

That's fair enough. I decided to try and make use of the 'regex functions'. I've got most of the way there, but some of my regex is still not quite right

I mainly come across this particular issue with some fanfiction (depends on the website) and webfiction (spacebattles, I'm looking at YOU).

[eschwartz]

I assume you use the FanFicFare plugin?

...

There may be something the plugin author can do, if it is a fairly consistent variety of source input. Best to ask about in the plugin thread, though.

Always best to catch these things at the source, if possible.

[sherman]

Originally Posted by eschwartz

I assume you use the FanFicFare plugin?

...

There may be something the plugin author can do, if it is a fairly consistent variety of source input. Best to ask about in the plugin thread, though.

Always best to catch these things at the source, if possible.

Yeah, FanFicFare for the most part, although there are sometimes over places I've got online fic and it hasn't used proper paragraphing.

[senhal]

First of all, thanks for this useful plugin!

If I add a cover using the Calibre Editor tool and then I apply Editing Toolbag to any tag, epub-check finds an error on the titlepage (the one with the cover):

ERROR	RSC-005	/text/titlepage.xhtml
(line 16, col 53)	Error while parsing file 'attribute "preserveaspectratio" not allowed here; expected attribute "alignment-baseline", [...].

I can't really see the difference, but some modification to the file is applied.

[jackie_w]

Originally Posted by senhal

First of all, thanks for this useful plugin!

If I add a cover using the Calibre Editor tool and then I apply Editing Toolbag to any tag, epub-check finds an error on the titlepage (the one with the cover):

ERROR	RSC-005	/text/titlepage.xhtml
(line 16, col 53)	Error while parsing file 'attribute "preserveaspectratio" not allowed here; expected attribute "alignment-baseline", [...].

I can't really see the difference, but some modification to the file is applied.

I can confirm this problem. In certain circumstances, something in the plugin is changing preserveAspectRatio to preserveaspectratio.

In case it helps to track down the actual problem, I have seen it when trying to remove empty spans, even though there are no spans at all on a typical calibre svg-type cover page. I can work around the problem by running the Editor's Beautify option before running this plugin.

[DiapDealer]

I'll have to take a look. I know that at one point, my code was taking extra care to preserve all the special camelCased svg attribute names, but perhaps I inadvertantly did something to break that. Should be pretty easy to fix if it is indeed my fault. It's weird that no one noticed until now, though, if so. This version has been in place for a long, long time now.

EDIT: Looking at the code, it looks like an oversight on my part. Everything works fine if the svg attributes are cased properly to begin with, but not if they're already improperly cased in the source. @jackie_w: that explains why Beautifying before running the plugin resolves it. Should be a fairly easy fix.

[jackie_w]

Originally Posted by DiapDealer

EDIT:... Everything works fine if the svg attributes are cased properly to begin with, but not if they're already improperly cased in the source.

I don't think this is correct. If you use the Tools - Add Cover option, the generated SVG code will have correctly-cased attributes. Running the plugin directly afterwards will mess-up the casing.

I believe the problem has something to do with the fact that the 'Add Cover' option creates

preserveAspectRatio="...">

on a new line. I tested this theory by changing the standard code so that

viewBox="..."

was also on a new line. Ater re-running the plugin both preserveAspectRatio and viewBox had changed to preserveaspectratio and viewbox.

Running Beautify before running the plugin removes the new lines.

Originally Posted by DiapDealer

It's weird that no one noticed until now...

My best guess is that a defective preserveAspectRatio attribute results in a default being used and perhaps the default is to assume preserveAspectRatio="xMidYMid meet", which is what most people would have set it to anyway. I only noticed the problem because I'm one of the Philistines who prefers preserveAspectRatio="none" for my covers

[DiapDealer]

Yes, being on a new line (after a linefeed character) could definitely trip up the plugin's tag/attribute-parsing routine. It's been a while since I've visited that. I'll have to experiment when I get in front of a PC. Thanks for investigating.

[DiapDealer]

After examining this issue, I'm thinking the simplest approach to fix it is to just exempt svg tags from scrutiny entirely. Otherwise, even after fixing the case issue, the plugin's parser is always going to alter svg tags that have extra spacing (including linefeeds and or carriage returns between its attribute/value pairs.

I can't imagine too many people are using this plugin to modify their svg wrappers to begin with.

Thoughts?

[jackie_w]

Originally Posted by DiapDealer

I can't imagine too many people are using this plugin to modify their svg wrappers to begin with.

Thoughts?

Obviously I can't speak for anyone else's usage, but I've never needed or wanted to 'refine' any SVG code with this plugin. I only use it for <div> and <span>.