Meeting minutes
shiestyle: This session is about next actions for digital manga and comics
… I am Shinya Takami from Kadokawa, and joined by Hadrien Gardeur from EDR Lab
Hadrien: I've been interested in this topic for a long time
… done my best to gather information from European publishers
… hopefully this session will ba good mix of feedback from Japan, Europe, and more
shiestyle: We're going to start with an overview of the situation in Japan, Europe, and NA
… then next steps for manga and comics
… four subtopics
… and then we will finish with any other business
… let's start
[Shinya shares slides]
shiestyle: The first presentation is from me, about EPUB in Japan
… [slide 1] ebook market in Japan
… 90% of the ebook market share is manga and comics
… $4bn USD in comics, 0.5b USD for everything else
… about 10% of the comics sold use the scrolled format
… it's not a small market for the Japanese industry
… the EPUB3 format is used mostly in Japan
… SVG wrapped image is used, and other formats
… many reading systems use only the images extracted from files
… and do not render the XHTML extracted from files
… SVG wrapped images to ensure images are scaled to the size of the screen
shiestyle: [example on screen] we use SVG <image> to declare the image
… in current web browsers, our XHTML is not rendered properly
… example on the screen is from Chrome
… differences in expected behaviour from browsers vs what we need
… the current web technology and reading systems diverge
… Japanese style only works on reading systems in Japan, XHTML and SVG are not necessary for reading systems, we only need the images
… we can reduce the size of the files by eliminating the wrappers
… if we don't use XHTML we lose accessibility, and image map
… we use image maps in FXL for manga content in japan
… If we don't use XHTML/SVG, we'll lose the image map features
… that is the situation in Japan right now
duga: Question, you mentioned that markup is doubling the size of the files?
Hadrien: Doublingthe number of resources, not file size
shiestyle: Doubling the number of files in the EPUB
davidhall: We seem to be using a few terms interchangeably
… digital manga, comics, webtooms
… I have a different idea in my head of that those are
… for me manga/comics are the same, paginated FXL content
… webtoons is variable-height and scrolled
… we may use the same solutions but there are differences
shiestyle: We can discusss webtoons later
wendyreid: What is the issue with the number of resources listed in the OPF?
shiestyle: Difference of cost to produce the EPUB files
… there's complexity
kevin: Thanks, interested in the problem in slide 5
… trying to work out what the problem is
… from an accessibility perspective, more flexibility in layout options and settings would be more important than the image appearance in the viewport size
… want to understand the nature of the problem presented
<shiestyle> ?
Hadrien: I can try answering
… one of the reasons bitmaps were wrapped in SVG was to achieve the accepted behaviour
… it was at one point required to get the dimensions contained
… it's not necessarily needed, it's a practice that has been followed, even though the historical reasons are not there
… to reply to David, it is confusing the different formats
… some is cultural, different terms and cultural expression in the media
… Korean, Japanese traditions
… it can be confusing, we are just trying to point out the variations
… and some have variations in design
… for example the requirement for bandes desinees are different, like resolution
CharlesL: For SVG wrapped bitmap images, is there any thought from publishers to use SVG directly, to benefit low-vision users in zoom?
shiestyle: No, we use it to fit to the screen
Hadrien: I'll mention this relating to Europe, there are some SVG use cases for other reasons
duga: Wanted to come back to slide 5
… not sure why this is a problem
… rendering in the browser is different from reading system, yes it is
… the reading system has EPUB to tell it what to do
… the browser won't render EPUB as it is to be rendered
… why is this a problem?
shiestyle: Many reading systems use browsers as their engines
… we need to customize the reading sytems to make this work
duga: This is what HTML gives you, the viewport
… yes, for instance, Play Books uses the webview to display the content
… but we display it as a formatted EPUB, using web engines
… regardless of browser
shiestyle: Depends on the reading system
<shiestyle> ?
duga: There is a spec to follow
Hadrien: Let's move to Daihei's presentation
hiroshige: How does the XHTML part play a role here?
… do we need to keep it?
shiestyle: It's used by the EPUB format
[switching slides]
Daihei: I'm Daihei Shiohama of MediaDO international and a co-chair of the publishing business group
… MediaDO is part of the Japanese market, and my part is based in the US digital publishing market
… I'm going to talk to you about the US manga and comics market
… manga dominates the comic and graphic novels market
… in 2023, manga was about 49% of units
… [stats on slides]
… the US market is dominated by print book sales
… the US manga market is projected to outpace the global manga market in growth
… global market is valued at 13.7 billion USD
… Japan, the US, and other regions will continue to grow
… digital books market are not accurately reported right now
… estimates are made, ebook sales are estimated at 10% of publisher sales
… several publishers launched proprietary apps in 2022-2024
… and several marketplace apps
… manga specialized app launches in the US
… ??? [which publishers?]
… webtoons market is projected to be worth 7.63 billion USD in 2024
… and reach 13.04 billion in 2032
… webtoons is a huge market too
… the top two webcomic platforms are owned by large asian companies, Naver and Kakao
… different business models
… print books are distributed and sold through different channels
… stores, direct, physical and online stores, crowdfunding
… manga is sold in Barnes and Noble, and ???? stores from Japan in the US
… online retailers, subscription and a la carte sales
<garykac> Kinokuniya? = Kinokuniya
Daihei: Webcomics are primarily distributed through speciality apps like Webtoon
… digital books are in EPUB 3 or PDF
… different formats in different streams
Hadrien: Go quickly, to give a few numbers, in France comics and manga takes up about 16% of the market share
… driven by large growth in manga
… drop in 2023, but growth overall
… comics have been driving growth in the book market in France
… mainly print
… digital about 5-6%
Hadrien: Webtoons is growing, driven from apps but small overall
… production, for large publishers production is in-house and automated
… different from what you see in EPUB production for reflowable content like novels
… it's completely automated with bitmaps
… big part is following the output from the automation
… smaller publishers are different
… unlike japan, there is no standard style
… some publishers do bitmaps in XHTML, others use SVG
… other examples of the visuals in bitmap, but the text is part of the SVG
… the text was selectable and available to screenreaders or TTS
… even seen bitmaps in spine with fallbacks to XHTML
… it's uncommon, but specialized platforms don't care about XHTML/SVG as long as they can get to the bitmap content
… the requirements are driven by large retailers
… many publishers mention Apple, their requirements for resolution drive their output
… happy to have maximum resolution improved, and influenced by that
… something that comes up a lot is the European Accessibility Act
… we've discussed this in the publishing maintenance working group
… they are concerned with the lack of information about FXL accessibility
Hadrien: I'll take us to the next topic
… it's been 10 years since EPUB for comics became common
… we now see what is working, what is not
… in the context of a future revision of EPUB, we have an opportunity
… concept of spread, spread placement
… placement is considered useful to publishers
… happy to have it
… it's fairly well implemented in reading systems
… at the spine level
… for each resource in the book, you can align it
… what we see is 2 patterns
… production workflows with 0 use of this property
… or another workflow where every resource has it
… I've seen many
… and we don't see cases where it's only partially used
… page-spead-centre is a bit strange, but useful
… it's useful as its aliased to spread:none
… good to avoid having a spread
… or for content creators to put entire spread in a single image
… it's used for covers
… it makes properties like rendition:spread redundant
… there's a disconnect between what the spec says and usage
… EPUB creators should use the page-spread properties when they want to ensure a spread
… we don't see this in practice
… the spec is advocating to use the properties sporadically
… they are used all the time, or none of the time, because of workflows
… when it's never used, authors expect the behaviours we see in apps like Apple Books
… there's an expectation of a behaviour that is not clear in the spec
… people seem happy and it's well-implemented
… it's useful
… there's another property, rendition-spread, for the entire publicatrion
… have a value at the publication level that is overridden at the spine level
… publishers use a template that uses "both" or "none", they hint at spread usage but it's not useful
… another miss is that the values are unclear
… auto is useless, landscape is weird
… gives control creators the illusion of content
Hadrien: It's always the user that decides what is best for them
… users view one page at a time
… scrolled
… there is a need for something different than what is needed in the spec
… I think what is needed is region-based navigation
… in comics, there are use cases where the reading order crosses the fold
… or usage where you need to see the entire spread
… there are elements that cross the fold
… [example shown]
… what is needed is the ability to display a spread when it is essential to the reading experience
… important to accessibility
… and let reading systems do smarter auto modes
… there are readers that scroll, but when you encounter a specific spread, it changes the interaction to side-to-side scroll
… the expression of information we do not currently have
… spread is hit and miss right now
duga: You talked about the illusion of control
… I believe PLay Books used to start with publisher said, but it was not beneficial to the user
… so we deferred to the usrr
… and in your example, that's a case where they needed to go together
… how do we make something that works here, publishers can tell us when it is meaningful
… how do we get the information when we really do need it
Hadrien: I don't think we need publication-level spread settings
… this is where abuse most often happens
… only allow at the spine
… and we should change the values
… none is handled by centre for example
… we need more a boolean, "this spread matters"
… if we had that, we could have modes that respect that
… but still work with user preference
… different information that is simplified to drive better defaults
… like if you detect it's used everywhere
… if we head off the abuse opportunities
Rain: I'm curious about anchoring on the spread as a publisher input
… I'm not sure how the spread is useful, if someone is zoomed in, the spread could be problematic
… I'm wondering if anchoring on the spread, you anchor on the cells
… "here's the cell of meaning"
… spread is outdated
Hadrien: I fully agree, and I can touch on it later
shiestyle: Let's move to bitmap and accessibility
Hadrien: What we see in practice is that HTML/SVG as containers is not often used
… we've seen image maps
… examples where text is in the SVG
… vast majority is a bitmap
… and container is there because it must be
… for specilzed reading systems that just rasterize everything
… SVG/XHTML was done for good reason
… but it's not moving the needle for accessibility
… one reason, unlike the rest of the EPUB ecosystem, there are a lot of specialized comics readers
… and they just display comics
… I think we cannot talk about that without talking about accessibility
… what we see right now in terms of EPUB capabilities, all we can do is create a script per page
… few EPUB out there that do it
… the content creator creates a script, they provide that as a description of the image
… and even that is inconsistent
… what do we need to create accessible comics?
… we need reading order at the fragment level
… fragment of an image, of multiple images
… useful to identify a unit of content
… like a panel
… another need is to have transcription of each fragment
… in comics there are a lot of captions, speech, sound effects
… it is often handwritten
… having it as real text is needed
… image description also needed at the fragment level
… there is a lot of content within a page
… we need to identify different areas
… if there is a panel, and the speech bubble, you need to know who is speaking and what
… there is a lot of visual information in comics
… how they are speaking, lots of contextual information communicated through visual means
… how to make all that conform to accessibility act requirements
… if we had a method, we could do more to serve readers, resize text, change fonts, speak aloud
… [gives example]
… [example of serialization of this]
… we identify a region, role, character, description, children
… there are other units of content
… speech versus shouting
… just an example
garykac: So I had a question about ordering and serialization
… sound effects may not be in order, but things like furigana that need to be in order
… in the example, how would I select a section or region of text
… I want to select at the character level
… doesn't seem useful for making the text accessible
Hadrien: I think you could define sub-regions
… even in the context of adapted content
… no one is doing this
… at the granular level, it's complex
shiestyle: For accessibility, as a publisher, it's not easy to prepare the pop-up text
… the description for each image is hard to prepare
… XHTML or SVG for EPUB is not valid in Japan for now
Hadrien: Publishers are concerned about the cost, especially in markets where comics are the fraction
ivan: Very practical question, we had the working group call
… we discussed areas to explore
… do you think what you described today, or part, is on the maturity level to be considered for EPUB 3 or needs more?
… where are we with this?
Hadrien: I think the spread stuff is ready to discuss, pragmatic revision
… if we're talking about accessible comics, it's very immature
… at best, this is a CG project
… way too early for the WG
Kamata: As a publisher, there was a significant cost to producing a frame-by-frame content view
florian_webirc: To get the full benefits of what garykac described, it seems to be is to realize is to not enrich the meta information
… but to have the text on the page
… the cost of producing such a thing, and the workflow is considerable
… vs text as markup on the page
… there is considerations of changes to the workflow
garykac: My assumption is its not possible due to how the content is produced, fonts, workflows, etc
… my assumption was it was not possible, but maybe?
florian_webirc: I'm uncertain we can realize the benefits of what you describe without doing the work to put the text on the page
duga: I saw a Japanese publisher show me a folio of the letterers and the fonts they developed for each one
… perfectly reproduced the style of each letterer with a font