enlarge the math?

[Turtle91]

Originally Posted by stumped

thats both.
yes my previous exposure to SVG was to simple wrap around tags

light grey is an exaggeration but it looks grey, not black, even in Sigil. Unless my eyes interpret a very narrow black "brush stroke" as grey, when it really is black ?

i will try to regex out the rgb % , if there's an way to point sigil find/replace at the svg definition, not at the xhtml files?

Just select "Current File" instead of "All HTML Files", in the mode of the regex selector.

[stumped]

Originally Posted by Turtle91

A little research later:
Apparently % in rgb definitions ARE a thing...


Found here.

You could still 'try' with rgb(0,0,0) just to see if your device/reader is choking on that point.

Cheers,

I am in sigil now, but i cant see how to use regex on only + all the svg definitions, which are within images, not within text section of epub

I assume no one actually just writes those long numeric strings, they use an app that converts pen strokes or an image capture into that format?

I also can't see where the xlink:href bits get used. they don't appear in the html code?
<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
<use xlink:href="#glyph3-1" x="32.265" y="3.676"/>
</g>

[Turtle91]

It appears Sigil doesn't like the %, and won't display them properly....so it is at least a possibility that is the issue.

Also, when you make a change in the svg file you need to reselect the html file tab to reload the image in the preview window...it doesn't update automatically until you do.

[stumped]

PS. I started the thread thinking that tweaking the book would be more fun that studying it- but I am starting to think the calculus would have been simpler to understand

[Turtle91]

Originally Posted by stumped

I am in sigil now, but i cant see how to use regex on only + all the svg definitions, which are within images, not within text section of epub

I assume no one actually just writes those long numeric strings, they use an app that converts pen strokes or an image capture into that format?

I also can't see where the xlink:href bits get used. they don't appear in the html code?
<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
<use xlink:href="#glyph3-1" x="32.265" y="3.676"/>
</g>

There are some geeks around that could probably build svg 'freehand', definitely not me....

You may want to see if it is a size issue making it appear grey for being too thin. If that doesn't affect it try getting rid of the percentages.

Make sure you are in the svg image file - not the html file.
Select 'Current File' and 'Normal' in the regex Mode:
Find: rgb(0%,0%,0%)
Replace: rgb(0,0,0)

[DiapDealer]

And there is currently no way to run a search on ALL svg files in Sigil. All HTML Files, Selected HTML Files, and Current File are the only choices for S&R scope. So you would have to open each svg file individually and do the S&R with "Current File" as the scope.

[stumped]

Originally Posted by DiapDealer

And there is currently no way to run a search on ALL svg files in Sigil. All HTML Files, Selected HTML Files, and Current File are the only choices for S&R scope. So you would have to open each svg file individually and do the S&R with "Current File" as the scope.

thanks, but there are 485 .svg files in the book. I may do a few, one at a time, as a learning experience, but I ain't doing all 485 that way!

Meanwhile, I opened up a different maths text and saw that in that one, all the actual math is stored as .png, and all looks solidly black. That's a more mainstream approach ?

[Turtle91]

Originally Posted by stumped

I also can't see where the xlink:href bits get used. they don't appear in the html code?
<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
<use xlink:href="#glyph3-1" x="32.265" y="3.676"/>
</g>

Again, I'm not an SVG expert, so take this with a fairly large grain of salt:

The 'symbols' are defined at the top. You would only need to define how unique symbols are drawn once...then you can use them multiple times in the same image:

<symbol overflow="visible" id="glyph3-1">
<path style="stroke:none;" d="M 3.515625 -1.265625 L 3.28125 -1.265625 C 3.265625 -1.109375 3.1875 -0.703125 3.09375 -0.640625 C 3.046875 -0.59375 2.515625 -0.59375 2.40625 -0.59375 L 1.125 -0.59375 C 1.859375 -1.234375 2.109375 -1.4375 2.515625 -1.765625 C 3.03125 -2.171875 3.515625 -2.609375 3.515625 -3.265625 C 3.515625 -4.109375 2.78125 -4.625 1.890625 -4.625 C 1.03125 -4.625 0.4375 -4.015625 0.4375 -3.375 C 0.4375 -3.03125 0.734375 -2.984375 0.8125 -2.984375 C 0.96875 -2.984375 1.171875 -3.109375 1.171875 -3.359375 C 1.171875 -3.484375 1.125 -3.734375 0.765625 -3.734375 C 0.984375 -4.21875 1.453125 -4.375 1.78125 -4.375 C 2.484375 -4.375 2.84375 -3.828125 2.84375 -3.265625 C 2.84375 -2.65625 2.40625 -2.1875 2.1875 -1.9375 L 0.515625 -0.265625 C 0.4375 -0.203125 0.4375 -0.1875 0.4375 0 L 3.3125 0 Z M 3.515625 -1.265625 "/>
</symbol>

glyph3-1 happens to be the number '2'

Then at the bottom it uses the href to reference which symbol to place at coordinates x,y

<g style="fill:rgb(0,0,0);fill-opacity:1;">
  <use xlink:href="#glyph3-1" x="50.209" y="4.745"/>
</g>

[Turtle91]

Originally Posted by stumped

thanks, but there are 485 .svg files in the book. I may do a few, one at a time, as a learning experience, but I ain't doing all 485 that way!

Meanwhile, I opened up a different maths text and saw that in that one, all the actual math is stored as .png, and all looks solidly black. That's a more mainstream approach ?

I wouldn't necessarily say "mainstream"...There are benefits to png...but svg is 'better' IMO...Mostly because it doesn't matter how large the image is it'll never get pixelated. If you try and zoom in too far on a png it can get all blurry and look like crap. Some publishers work around that by having very large resolution files...at the expense of having a VERY large ePub file size.

If the % thing is the actual cause, then it would be super easy to open the ePub in a different editor, such as notepad++, and you could easily regex all the svg files in one go.

The css/html files are easily edited in sigil with a couple regex.

Personally, I would only have a few svg 'classes':
1) for equations that are inline with the paragraph, such as:
span.inlineEQ img {height:1.2em}

2) for smaller equations on their own - like only a single line with numerator, denominator, exponents, etc, such as:
div.smallblockEQ {text-align:center; margin:1em 0}
div.smallblockEQ img {height:2em}

3) for larger equations on their own - like multi-line proofs, such as:
div.largeblockEQ {text-align:center; margin:1em 0}
div.largeblockEQ img {height:10em}

Then you would only need a specific class for the truly freaky equations.


edit:

Having said all that about svg being better....I think there are some, older, readers/devices that don't like svg within the body of the html...they only play well with an svg wrapped jpg/png/gif/etc as a cover image. Someone else around here could probably tell you which devices still struggle in that regard.

[jackie_w]

Originally Posted by stumped

those SVG images display as intended in Moon +. no missing/empty boxes.

Lucky you. As stated in my previous post, images with a .svg filetype don't display (except as an empty box) in my copy of Moon+.

Anyway, there's little point pursuing this difference of opinion.

[DiapDealer]

Originally Posted by stumped

thanks, but there are 485 .svg files in the book. I may do a few, one at a time, as a learning experience, but I ain't doing all 485 that way!

That's what I figured. Just wanted to make sure you knew what you were in for.

[stumped]

ok folks another test, another question ( about conformance with epub specs)
i sent the book with the svg stuff in it to Kobo forma, via dropbox. i.e. as an epub, bypassing any epub -> kepub processing.

its like with ADE2, blank spaces where the svg defined equations are supposed to appear. ( i do see the large graphs though - because they are stored as .png.

new question : is the book out of spec in expecting all epub devices to handle its .svg content, or what ?

why can't ADE, kobo cope at all .
Perhaps JSWolf can explain why Moon reader ( which he hates and) hugely outperforms his beloved Kobo devices in this case.

lets try the various checkers built into sigil... incidentally this book sometimes completely fails to open in sigil task manager confirms sigil has gone awol - or takes 2 -3 minute to open in Sigil on a 2nd try - on a fast PC ... and then it appears twice!

well the f7 check says no problems. that seems to be the only check now bundled into Sigil. I will go see is calibre editor has additional ones but I suspect it will pass whatever tester i find.

untried for now:
an epub->kepub conversion
any later version of ADE ( i use the old v2 that plays nicely with ALFs tools)
bookari on tablets

[DiapDealer]

Originally Posted by stumped

ok folks another test, another question ( about conformance with epub specs)
i sent the book with the svg stuff in it to Kobo forma, via dropbox. i.e. as an epub, bypassing any epub -> kepub processing.

its like with ADE2, blank spaces where the svg defined equations are supposed to appear. ( i do see the large graphs though - because they are stored as .png.

new question : is the book out of spec in expecting all epub devices to handle its .svg content, or what ?

why can't ADE, kobo cope at all .
Perhaps JSWolf can explain why Moon reader ( which he hates and) hugely outperforms his beloved Kobo devices in this case.

lets try the various checkers built into sigil... incidentally this book sometimes completely fails to open in sigil task manager confirms sigil has gone awol - or takes 2 -3 minute to open in Sigil on a 2nd try - on a fast PC ... and then it appears twice!

well the f7 check says no problems. that seems to be the only check now bundled into Sigil. I will go see is calibre editor has additional ones but I suspect it will pass whatever tester i find.

untried for now:
an epub->kepub conversion
any later version of ADE ( i use the old v2 that plays nicely with ALFs tools)
bookari on tablets

F7 is only a quick well-formedness check. All tags are closed and no bad nesting. It doesn't do any spec-compliance checking at all. Sigil is out of the validation game. Use the EpubCheck plugin to check compliance.

When there's a compatibility issue, it's usually safer to assume that it's the reading system falling down and ignoring epub spec, rather than the epub failing to comply (though that's possible too). The problem with compliance is that every reading system out there has a different interpretation of the IDPF's wishy-washy "may/might/should" wording.

[stumped]

ok thanks.
to further thicken the plot re this book.
I see that Kobo store actually sells an epub3 version. Looked at the preview but the couple of equations within that seem to have been separated out into not-inline images.
there's probably a multi step way to grab the kobo store preview, de-drm it and open it up to see what they have done, but I am not that motivated. calculus in 5 hours is in kobo store ( UK or USA)

its definitely time to change textbooks. I am persevering with this one only to better understand the whole .svg issue.


looking back at what I'd been doing. I discovered that had started with an epub3 version and reduced it to epub2. so i got my epub3 version onto the forma, only for it to freeze and reboot the device almost every time i try to open it !
and when I did get it to open on the forma, the equations were still missing.

[DiapDealer]

With EPUB3, they could have gone full-blown MathML to display the formulas. How did you do your EPUB3 to 2 "reduction"? It's fairly easy to go the other direction, but 3 to 2 can get quite involved if it's anything other than a vanilla, text-only book.