See also: IRC log
<trackbot> Date: 23 March 2015
<scribe> scribe:NickRuffilo
<scribe> scribenick:NickRuffilo
!scribenick:NickRuffilo
<tzviya> agenda https://lists.w3.org/Archives/Public/public-digipub-ig/2015Mar/0022.html
<tzviya> scribenick: NickRuffilo
<ivan> Chair: Tzviya
Meeting begin!
<tzviya> https://lists.w3.org/Archives/Public/public-digipub-ig/2015Mar/0019.html
Tzviya: "Any comments on the notes from last
meeting?"
...: "Minutes approved."
<tzviya> http://dev.w3.org/csswg/css-break-3/
...: "Next agenda items - review/comments on CSS fragments from liza and
brady."
Brady: "Not sure who has read the spec of css-break - introduces fragmentaners. Covers page-break, column-break, fragment-break, etc. How that works in various situations, floats, etc. Seems obvious but it's actually a lot trickier than it sounds, so it goes into lots of details. I've posted some comments. No responses yet, but I just posted them. Overall spec looks good, tackles difficult area, and would be great to have it implemented."
Ivan: "Can you post a link to reply?"
Brady: "I'm doing multiple replies, but everything has CSS-BREAK in the title."
Ivan: "In the WWW Style mailing list, right?"
Brady: "Yes"
<astearns> many threads here: https://lists.w3.org/Archives/Public/www-style/2015Mar/
<ivan> comments on the www-style mailing lis
Liza: "I reviewed it in the context of
having implemented pagination using web technologies (aka terrible hack
using something existing like columns or regions or by hand). For me,
the problems I was looking for this to solve - which is solves some and
not others - such as how to break up complex object like tables. There
are some rules on how to break out tables. What I found is that a lot of
concept we have at Safari, in which this spec doesn't address, is with
placed elements like images, video, and movable blocks. So if you were
making print-layout, you would deal with widows, orphans, images by
making the page smaller and dealing with those cases individually.
Certain kinds of content wouldn't find this solution particularly
attractive as it would still wouldn't work wonderfully for highly
disjointed content. Images, widows, captions, etc."
...: "This won't solve those issues, but it will solve lots of other
complex layouts. Most of publisher content will still not make
publishers feel like pagination is a solved problem."
Brady: "I agree with that. It does not handle the dynamic reflow you want when dealing with pagination. Unfortunately I don't quite understand how tables break if you're breaking within a table-row. Easy to break within the boundaries, but not sure how a page has multiple page-breaks"
Alan: "I believe multiple-page-breaks is trying to address that. The section on parallel flows. Examples may not be sufficient or explicable, so feedback on that would be wonderful. Spec is just on how things are layed out, but nothing on how fragment containers are adjusted. Interesting to see if resizing monolithic elements within a container is possible within break opportunities. It tries to deal with widows/ophans and captions in check. You can have breaks prohibited between paired items. Only issue is when the two items are unable to fit within the unbreaked container."
Liza: "Surprised to see lots of examples where the page size varied from page-to-page. It would describe the behavior if the pages were extremely varied different sizes. Only time I would see something like that in real-life publishing is if a page went from portrait to landscape."
Alan: "Happens more in magazines when you go from full-page to column-based layouts. Most of CSS assumes you have a particular length to work in."
Bill: "I can be brief: Thanks to Tzviya and Ivan we've made great leaps forward. The Wiki (link above) has a good group of people signed up, but more are welcome. What Tzviya contributed was a great start on a background section. Earlier, Ivan started to develop a strategy around how we would identify identifiers that are specific to media types. Just use them, don't define them. Secondly identifiers that get you into the package/some place within the package. Please read the Wiki as there is wonderful information in there."
...: "I will see if Tzviya/Ivan have anything to add."
Tzviya: "I think we may just want to outline the goal of the TF."
Bill: "The overarching goal is identifiers in general for ebup web. Identifying the publication will be messy, so lets first start with identifying fragments. Ideally the outcome is to recommend to the W3C refinements to the existing spec or some other solution that gets us where we need to get. Now we need to identify fragments as that will be important to annotations and other sections of publishing."
Tzviya: "Ideally we take an existing spec with no changes, IDEAL world..."
Bill: "Thats the thing we've identified. Noting what is needed and hopefully we find that is already out there and the diffs."
Liam: "We have a framework for XML document
called XPOINTER where you name a scheme - cfi or xpath, that is probably
worth looking at as it provides you the ability to define what you're
pointing at and the pointing mechanisms."
...: "People have been doing it for 20 years which is fairly robust to
changes/namespaces"
Ivan: "In a sense, my view is that XPOINTER is something we should - of course - use as a black box, as well as all the other fragment identifiers for different media types. Because they are there and we should not reinvent the wheel. What is unique is that we have a package and we have to find a way to get into the package. To all the various schemes in the background, only CFI and those that are in the package, are those that are too be reviewed, critisized, etc."
...: "What both do is start with the package, then
identify the document within the package. The 2nd step is to go within
the document which is in the package. The CSI doesn't do a really good
job because they also specify the fragment into the HTML document, which
should be left to the XPOINTER. The goal is to get to the document when
starting within a package. I have tried to collect the requirements for
having such a mechanism. Whether those requirements are the right ones,
or if there are others to be looked at, that is something we need to
find together. For example: My understanding of CFI is that actually it
can go through several documents from the package. From the Package you
can get to HTML, then to an object, then to something else. So it hops
through steps before getting to a media type, something that the package
identifier does not do."
...: "Not sure this is a requirement for the publishing industry or not.
If it is, it is something we need for the web packages. CFI doesn't lose
any of the fragments. My preferences would be to rely on fragment
identifiers."
... "That would be a way for us to focus on what is specific."
tzviya: "part of it has to do with how we get inside the package, which is dependent on HOW we structure the package..."
Ivan: "Indeed. the CFI and package fragment take a different part simply because the package is different. But they do the same thing."
Markus: "Two things. First - when it comes to fragments - we have many simple questions to ask. Given the HTML document that is part of the package. I want to define something that is a text-fragment, is there a way for me to do that today? What are the things we would need to do to allow that? That's pretty straight-forward, but we need to list the requirements but we need to list the stuff that we would want to identify."
mgylling: "I wanted to - in terms of ultimate goal - which pertains to fragments, paths, and identifiers, it isn't just about packages. If you look at it from the whitepaper, it shouldn't matter if the package is an archive or exploded and online. If I create a URI, that URI should look the same no matter what the publication is (archive or online) which is an important thing to remember moving forward. If we don't get there, we will end up reinventing things with different syntax, but we've painted ourselves into a corner. We shouldn't have syntax based off a state of the publication."
Ivan: "we have to deal with the most specific one - identifying something within one document; The classical fragment issue. Must have a clear idea on what our requirements are on this term. What I'm saying is that we should at least try."
<tzviya> me/ hi, dave - still on
fragIDs, already did CSS fragments
...: "If it is an xpointer scheme we haven't implemented yet, ok, but we
need to reply on it. The fundamental approach should be - whatever
possible, rely on existing fragment IDs. This is one end of the
spectrum. The other end of the spectrum is identifying a BOOK or a
document. Which is about giving an identifier. This is complicated
because it isn't a fragment, it's in the Identifier world, which is
messy. There is something in between which is a different set of
requirements. "
Bill: "I thought we were going to have a TF call? Should we have the call, or have the discussion via e-mail?"
Tzviya: "Conversation started on the list, then schedule a call."
<tzviya> http://w3c.github.io/dpub-pagination/
Dave: "update is that there isn't much to update. Where do we go from here? Prince is using it as a blueprint for book products to try to increase the value of that PDF forematter. I would love to add/flesh out more too it, but not sure what I should be adding right now. Contributions/comments are very welcome!"
Nick: "What is latinreq?"
Dave: "How page layout should be done in
western languages. Inspired by JLreq - spec for japanese. What do they
do for pagenumbers, running headers, typesetting, line-heights,
headings."
...: "Alot of this stuff has not been written down anywhere. Just been
the oral traditions of typesetters and composition people. For the
web/electronic documents, been trying to write it down."
Markus: "What happened with JLReq - it was completed, finalized, then the editors retired. Do you see latinreq as a living rec that will not go that path? Or should we maintain the idea of completeness/final?"
<tzviya> http://w3c.github.io/dpub-pagination/
Dave: "I have no intention of ending things.
So I think of it as a living thing. I would like it to keep evolving and
getting bigger/better."
... "Edits will ebb/flow, based on the community and people who are
willing to help. In this case, I don't want to declare victory and go
home. I feel like there is much more."
Tzviya: "There were some areas we would hope there would be work with other communities, such as STEM. We might find the results of Peter's survey we might have additional information, such as equations, etc."
<pkra> +1
Dave: "We'll take contributions in any forms. Sketches, examples, etc. I'll do the formal writing, but I need feedback/input"
Alan: "Liza brought up something with fragmentation spec - how publishing deals with fitting monolithic content into fixed-size page. There might be useful notes in latinreq about how such content fits within it's containers."
Tzviya: "Page-break-inside, etc. Sometimes it works, sometimes it doesn't."
Alan: "Based on the aspect ratio, the caption could be on the left, right, a different page (the facing page, etc)... Lots of things that happen around the placement of captions relative to images."
Tzviya: "Another issue we discussed is
tables. Not sure we discussed diagonal headers... Probably a good
discussion about offline."
...: "When the header is on an angle, but the body content is normal.
Timetables are often done like that."
Tzviya: "if you have examples of wacky content, Dave can write it up."
<ivan> action-21 ?
<trackbot> action-21 -- Peter Krautzberger to Publish first draft of stem use cases and pain points summary -- due 2015-02-28 -- OPEN
<trackbot> http://www.w3.org/dpub/IG/track/actions/21
Peter: "We are deferring this..."
tzviya: "We need to prioritize. Peter has
too many action items."
...: "Will this come out of the STEM survey?"
Peter: "Yes."
... "Survey going out this week, so we'll be able to do this after
that."
<ivan> action-27?
<trackbot> action-27 -- Peter Krautzberger to Compare mathml tables with html, and write it up on a wiki page -- due 2015-03-19 -- OPEN
<trackbot> http://www.w3.org/dpub/IG/track/actions/27
Peter: "I have done some work, but it hasn't been completed. Can we just push this? I need to do some stuff for the math working group. The STEM survey has my priority."
Tzviya: "Do you want to bring this task to the Math working group and have them do this?"
Peter: "Yes."
<ivan> action-31?
<trackbot> action-31 -- Karen Myers to Initiate business use case -- due 2015-01-31 -- OPEN
<trackbot> http://www.w3.org/dpub/IG/track/actions/31
Tzviya: "We'll change this to 'by the math working group'"
<ivan> action-34?
<trackbot> action-34 -- Peter Krautzberger to Send stem survey -- due 2015-01-31 -- OPEN
<trackbot> http://www.w3.org/dpub/IG/track/actions/34
Karen: "Yes. I've made some progress, but please give me 2 weeks. Wnat it by first week in april"
<ivan> close action-34
<trackbot> Closed action-34.
<ivan> action-42?
<trackbot> action-42 -- Ivan Herman to Find someone to review i18n web page -- due 2015-01-15 -- OPEN
<trackbot> http://www.w3.org/dpub/IG/track/actions/42
<ivan> close action-42
<trackbot> Closed action-42.
<ivan> action-43?
<trackbot> action-43 -- Tzviya Siegman to Dpub to read i18n documentation from epub perspective for gap analysis -- due 2015-01-31 -- OPEN
<trackbot> http://www.w3.org/dpub/IG/track/actions/43
<ivan> close action-43
<trackbot> Closed action-43.
<ivan> action-44?
<trackbot> action-44 -- Markus Gylling to Talk to brady about fleshing out the pagination use cases -- due 2015-01-19 -- OPEN
<trackbot> http://www.w3.org/dpub/IG/track/actions/44
<ivan> close action-44
<trackbot> Closed action-44.
<ivan> action-45?
<trackbot> action-45 -- Brady Duga to Add information to personalization use cases -- due 2015-02-16 -- OPEN
<trackbot> http://www.w3.org/dpub/IG/track/actions/45
<brady_duga> I dropped (deadzone), but I think I still have something to do on 45
<brady_duga> I forgot it existed - sorry
<ivan> action-46?
<trackbot> action-46 -- Tzviya Siegman to Contact the html wg for a working definition of footnote -- due 2015-02-16 -- OPEN
<trackbot> http://www.w3.org/dpub/IG/track/actions/46
Tzviya: "Two weeks will be added to give Brady time."
<ivan> action-47?
<trackbot> action-47 -- Thierry Michel to Create new wiki for identifiers tf -- due 2015-03-02 -- OPEN
<trackbot> http://www.w3.org/dpub/IG/track/actions/47
<ivan> close action-47
<trackbot> Closed action-47.
<ivan> action-48?
<trackbot> action-48 -- Peter Krautzberger to Gather font metric info from the mathwg for houdini -- due 2015-03-09 -- OPEN
<trackbot> http://www.w3.org/dpub/IG/track/actions/48
<pkra> Sorry I dropped off the call.
<pkra> This was actually two items.
<pkra> a) use case of font metrics for MathJax / MathML polyfilling
Tzviya: "Hoping peter can get in touch witht he Match working group"
<pkra> b) talk to MathWG about other use cases.
<dauwhe> Link for Houdini Font Metrics spec: http://dev.w3.org/houdini/font-metrics-api/
<pkra> a) I have started on
<pkra> b) I will bring up on the next call with the MathWG.
Tzyiva: "Is there anyoen else who can help peter with this?"
<tzviya> thanks, Peter - is 4 weeks enoughs?
<pkra> tzviya yes, 4 weeks will do it.
<tzviya> https://www.w3.org/dpub/IG/wiki/May_2015_F2F_Logistics_and_Details
Tzviya: "we have May meeting scheduled for
26th May, NYC. Please add your information to the wiki to let us know
you're coming. We would like to start planning the agenda."
...: "I think we also talked about broader issues, such as packaging."
Markus: "Rather than just having reports, which we do on these calls. So bigger topics such as packaging."
Tzviya: "Please add your name to the May
meeting. If you're in the new york area, please show up. It's the time
for IDPF and BEA. Information for hotels is there. Book early."
...: "TPAC? in Sopporo Japan. We are supposed to respond to a
questionnaire. Organizers need to know if we're going."
<ivan> TPAC: Week of the 26th of October, Sapporo
Ivan: "I think the TPAC meeting is a little different than the previous. Going through the TF reports we can do elsewhere. What was very useful in the last one was to talk to a number of other groups. That would be one of the main reasons that having the meeting there would be important, even though I realize not many people will show up. Having our voice heard is important. Other things we should try to do is we have unfortunately only a few people from east-asia in the group and this is a chance for their voices to be heard."
<tzviya> http://www.w3.org/2015/11/TPAC/
...: "Also good to get a japanese/east-asian perspective. We should give
a slightly different view on the meeting and try to have it."
... "IETF meeting there as well previous, so Heather may be there as
well."
Markus: "In the next 2 months, the IDPF is
collecting suggestions for the upcoming epub 3.1 revision. Which will be
proposed in May, and kickoff in the summer/end of year. 3.1 is first
revision that IDPF is running in the lifetime of Digital Publishing WG
and since the relationship and desire for convergence. That said, 3.1 is
not the new big epub web, but an increment to the existing."
...: "There is an opportunity, even though it can't be dramatic, to
propose features/change requests based on our work. If you're interested
in coming up with such proposals/suggestions, feel free to contact me."
Ivan: "Typical case - something that may come back to bill - if you take a look at the document that the Metadata group produced, there are very specifically things that we say "The open web platform has the technologies to do this. The DPUB WG may not use these technologies yet. These are the things that may come to this."