Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Request to allow JPG/PNG images as content documents #240

Closed
GoogleCodeExporter opened this issue Mar 24, 2015 · 16 comments
Closed

Request to allow JPG/PNG images as content documents #240

GoogleCodeExporter opened this issue Mar 24, 2015 · 16 comments

Comments

@GoogleCodeExporter
Copy link 

I would like the WG to consider a request to allow JPG/PNG images as content 
documents, so that EPUB publications can have JPG/PNG spines without fallback.

Benefits are:
1. Simpler to create image-based publications
2. Smaller file size. Some publishers limits the file size of publications, so 
this allows more quality of the image files.
3. More use of JPG/PNG spines. Even though authors can use images with fallback 
today, the behavior is unstable on some RS and authors are hesitant to use it. 
However, from RS performance point of view, JPG/PNG has perf advantages than 
SVG/XHTML and is preferred.

Original issue reported on code.google.com by kojii...@gmail.com on 18 Sep 2012 at 12:18
@GoogleCodeExporter
Copy link
Author 

https://groups.google.com/forum/?fromgroups=#!topic/epub-working-group/YEk2f2N6a
mQ

Original comment by kojii...@gmail.com on 18 Sep 2012 at 12:22

@GoogleCodeExporter
Copy link
Author 

[deleted comment]

2 similar comments
@GoogleCodeExporter
Copy link
Author 

[deleted comment]

@GoogleCodeExporter
Copy link
Author 

[deleted comment]

@GoogleCodeExporter
Copy link
Author 

Issue 256 has been merged into this issue.

Original comment by markus.g...@gmail.com on 2 Mar 2013 at 11:09

@GoogleCodeExporter
Copy link
Author 

[deleted comment]

1 similar comment
@GoogleCodeExporter
Copy link
Author 

[deleted comment]

@GoogleCodeExporter
Copy link
Author

Original comment by bkasd...@apexcovantage.com on 12 Apr 2013 at 5:54

  • Changed state: NeedsDiscussion

@GoogleCodeExporter
Copy link
Author 

I'm generally in favor of this addition, but the question will be what do we 
say about sizing/styling of these "naked" images?

Original comment by ga...@google.com on 12 Apr 2013 at 6:12

@GoogleCodeExporter
Copy link
Author 

The consensus has been reached to allow a "@wraps" on the <itemref> to indicate 
to a reading system (if it chooses to care) that the spine item simply wraps 
the referenced image.  The reading system could render the referenced image 
directly, if it so chose.

I propose the following specification for how the image should be directly 
rendered (if the Reading System chooses to render the @wraps -referenced image 
rather than the @idref -referenced content document).

The image should be rendered as if it was included  in the following template 
Fixed Layout ("layout: pre-paginated") spine item:

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="viewport" content="width=<image-width>, height=<image-height>" />
<title></title>
</head>
<body style="width: <image-width>; height: <image-height>">
<img src="<image-path>" alt="<image-path>" />
</body>
</html>

"<image-width>" should be replaced with the pixel width of the image.
"<image-height>" should be replaced with the pixel height of the image.
"<image-path>" should be replaced with the relative path to the image file.

Original comment by ga...@google.com on 1 Jul 2013 at 10:45

@GoogleCodeExporter
Copy link
Author

Original comment by ga...@google.com on 1 Jul 2013 at 10:46

  • Changed state: ProposedSolution

@GoogleCodeExporter
Copy link
Author 

What do we have to add in spine itemref?
Also what about styling/sizing of the image?

Original comment by ori@helicontech.co.il on 16 Jul 2013 at 4:17

@GoogleCodeExporter
Copy link
Author 

See panel #10.  Adding an (optional) @wraps to <spine> itemref's to point to an 
image to give the reading system an option of directly rendering that rather 
than the <itemref>.  The sylting/sizing is as specified for Fixed Layout -- and 
inherits those sizing, centering, letter-boxing rules.

Original comment by ga...@google.com on 16 Jul 2013 at 5:03

@GoogleCodeExporter
Copy link
Author 

Sorry I'm not following all threads, but can you clarify what @wraps points to? 
Is it a relative URL to the image, relative to OPF file? Is it an IDREF within 
OPF file? Or something else?

Original comment by kojii...@gmail.com on 16 Jul 2013 at 11:47

@GoogleCodeExporter
Copy link
Author 

The (optional) @wraps attribute on a <spine> <itemref> would be basically just 
like the @idref attribute -- however, it would reference the @id of a 
<manifest> <item> that was an image that the @idref-referenced content document 
simply "wraps."

Original comment by ga...@google.com on 17 Jul 2013 at 12:13

@GoogleCodeExporter
Copy link
Author 

Due to the inability of the WG to reach consensus on this issue, and after 
discussions about the situation with the IDPF BOD, it was resolved at the 
20130815 WG call to defer this issue from 301.

Original comment by markus.g...@gmail.com on 22 Aug 2013 at 9:06

  • Changed state: Deferred

@GoogleCodeExporter GoogleCodeExporter mentioned this issue Mar 24, 2015
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@GoogleCodeExporter