I think you're looking at code which is an embedded graphic. It is no longer vector.
If you exported the EPUB from InDesign, you may have (perhaps inadvertently), selected a vector graphic and chose Object > Object Export Options with settings which rasterized the graphic.
Oh, and I thought I would know InDesign and ePub. But it looks like the InDesign developers have integrated a new surprise with InDesign CC2015.
Base64 encoding is only for experts and special cases. Whoever integrated this in ID has maybe experience in web-design, but didn't notice that ePub is different, even if they are based on the same technology.
The only workaround is to link your vector images from an ai/eps instead of embedding the vector pathes in InDesign.
I do it, everytime. No graphics exported without some object style of such kind.
that is to say,
1. import vectors into Illustrator
2. check it is still looking ok, and save a file as ai/eps
3. import the file as a link into ID
For one file, it is ok, but what about 50 files?
I still don't understand why I cannot rule whether my graphics would have been rasterized as a linked object or not.
If you are using Mac CS6 or CC2014. We have a demo / beta script that will rasterise the contents of a spread. You can also mark items to be rasterised together.
I cannot deliver an answer, but this problem is really weired: InDesign should create a file and link it – and not put the image data directly into the html code.
In my case, this problem even appears with the same Adobe Illustrator file: one artboard is properly exported as .png, a second artboard is exported as src="data:image/png … ".
My export options used InDesign for Image Conversion is «Automatic». For sure, if I change this to the specific type JPEG: the output is fine in the chosen format. But if I chose PNG, then the exported image will still be data:image/png … Automatic is the only way to keep automatically graphics as png and images as jpg without the need to define the export option for each linked element.
Apparently: Size matters. The same AI file in a box with different sizes is exported differently: once as linked image (when bigger), once as data:image (when smaller)
Two factors are playing a role: the box size and the data complexity/size of its content.
And: CC2015 is affected by this programmatic ambiguity, in CC2014 this problem does not exist.
Does anyone know how to control better this output?
I can tell nothing about the reason.
But can you spot a difference between the two placed artboards?
Maybe the one is not nested inside another object?
And the other one is? (nested inside a group, pasted inside a frame anchored to a text frame …)
Maybe you can avoid the problem, if you can find out the difference.
Yes, and my question is still: "Why I cannot choose which way to export?"
I still do not use InDesign CC 2015 for production purposes. It's just in my evaluation and testing phase.
So I'd like to ask: What is the problem with base64 encoding "inline" with the HTML of your FXL EPUB?
Does it not validate?
Are there problems with EPUB reading software?
I already read this here:
"Everything would be ok but some shops meet problems to upload such epub to their system (eReader), because the object is unseen at all."
What exactly does that mean?
A provider is rejecting your EPUB file because the image is not saved to a file?
A provider is rejecting your EPUB file because the inline image cannot be viewed in the EPUB Reader?
Some shops selling epubs containing such coding suffer technical problems. It cannot work properly. If you want I can try to ask details.
Let me check it.
As I understand there are some encryption (DRM) issues. Does it help you some?
I ran into this same "new behavior" a couple of weeks and it killed me on a project. I did a lot of testing, and finally concluded that it is probably the total output pixel dimension, or output file size in bytes that determines when and if an image is encoded in the EPUB/HTML output instead of linked. But I couldn't determine what that threshold was.
Thanks for your reply. For a better understanding, here a short description of my testbed:
The thing is, there is no difference between the artboards. They are in the same Adobe Illustrator file and the original artboard size is also the same.
On it, I put for testing purpose only a few different rectangles (Screenshot 1: Three artboards in a Adobe Illustrator file with different rectangles).
Then, in InDesign, I made a testbed (Screenshot 2: One page document in Adobe InDesign):
Graphics 1 and 2 will be a linked image after HTML output, graphic 3 (box crops a part of the graphic form) becomes an src="data:image/png …" (Screenshot 3: Inspection Element in Safari from HTML output):
With the only change to make the box of graphic 3 bigger (Screenshot 4: One page document in Adobe InDesign) …
… things change (Screenshot 5: Inspection in Safari from HTML output) So, all three graphics will be exported as .png.
Don't get confused with the file names «Vectors_A.png, Vectors_A1.png …» they are set automatically, so Vectors_A.png describes not the same in Screenshot 3 and 5 …
Ah, I think Keith Gilbert is on the right track.
If the file size (maybe in combination with pixel dimensions?) of the JPEG or PNG information in binary form is going below a particular value, the image data will be injected inline into the HTML. Would that be a working theory?
what do you call "jpeg"? the original sitting in my layout, or the one IND creates (or sometimes doesn't create)?
I ask it because usually the problem happens in case when the exported thing is not a picture but some kind of grouped objects, lines, vectors..
Same finding, same theory (at Laubender).
So as you also did a big effort in testing, from my point of view it seems insolvable from the user side.
It does not only happen with small vector images, but also with very small pixel images, if the configuration «Copy images» is set on «optimized».
If you look into the encoding you can see the expected file type of the encoding:
<div class="_idGenObjectLayout-1"> <div id="_idContainer013" class="pics"> <img class="idGenObjectAttribute-2" src="data:image/jpg;base64,/9j/4AAQSkZ … //Z" alt="" /> </div> </div>
To this problem: if you watch carefully the html export of InDesign, all necessary files are generated – but then again deleted if too «small» and directly set into html code.