RSE Wiki Archive

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Attendees: Heather, Tony, Paul, Julian, Nevil, Alice, Robert

Apologies: Joe, Sandy (handing back off to Alice)


0. Agenda bash

1. XML vocabulary and page layout

- is the vocabulary really the place to solve for page layout issues?
Reviewed the DocBook XML schema (http://www.docbook.org/schemas/5x) and the PRISM schema (http://www.idealliance.org/specifications/nextpub/specs-and-guidelines), and as far as I can tell, neither has page layout hints.

- this argument is being held because people expect what they see now, and aren’t considering the new formats and what that really means

- one suggestion on rfc-interest was to move the heuristics on end of paragraph into the xslt; when Julian allowed for that, it just moved the break into another bad place.  This is too much micromanagement.  Any feature that allows people to fine-tune the algonrithm, mean that A, it will have to be implemented in the formatter, and b) people will spend endless time fine-tuning the document so the page breaks are in the right place for the font and format they prefer, and it will be useless for any other output format.

- people are used to this, but they are used to it because humans are working on the final bit.  We are now only making one output once, so this is a one time cost per document.  

- we are also talking about the RPC losing the ability to adjust those outputs.  

- Proposal: in the vocabulary, we could say that you can add extension attributes in a different XML space and it will validate, and formatters would be able to ignore all of those.  For people who are really interested, people could provide their own implementation to take those into effect.

- The one place where it is important to have this is the places where we would have used pre- or post-ambles around figures and tables.  Previously, those were kept with their associated figures and tables.  The code kept them together.  We have lost that ability.  

- IF we leave the vocabulary as is, at least for the cases in the web aspect, Julian would add a heuristic to keep them together.  If a paragraph in front of a figure is short and ends with a : then it should be kept with the figure or table.  How many of these use cases could a part formatter deal with.

- not sure trying to define all the usual use cases is actually going to be useful

- in CSS, you have three states: page break always, page break never, and page break avoid.

- if we go to having an attribute that says “please try to keep this with the following thing” we also need an attribute that says “please don’t break this thing if we’re trying to keep it with something previous"

- if we said, for the paginated outputs, would Tony be happier if we said, each time the RFC Editor generates these, that a human has to go through and look at them and review the typesetting.  This is likely to be an outlier case, but it is something to consider.  If we have no hint AND this seems important, how will it get done.  If it gets done by people, we need to say that.  If it is done through the vocabulary, what are the semantics of the hints we’re using.  Paul will do that, but not to make just one person happy.  Paul like Juilan’s suggestion of having those people work on this separately.

- Could put in a straw man within the draft, recognizing that the draft is going to be a draft for a while.  Tony suggests attributes that could be added to specific elements; Tony will post to rfc-interest.  

- concerned that we come up with hints that are not implementable with HTML and CSS.  The sooner we have the proposal and shows what the HTML will look like, the better it will be be.   If we do add this, there needs to be an expectation that it will work.

* HF to take her concern re: XML -> HTML -> PDF to the list
  Summary of list conversation, for the record:  This is mostly a tools team decision.
  Don't waste time/money doing this the hard way.
  
- the same pattern of conversation with keep before/keep after will happen with two spaces after a period.

- in the tooling requirements in the formatters today, we don’t have anything about allowing extensions, or anything that talks about removing elements from other name spaces.  It is valid to have attributes in an extension name space (RelaxNG allows that) and the formatter will ignore them.  The people can put extension attributes and work on them directly.  Robert would like to add a bullet to cover this; Julian suggests “will strip any attribute not in the default namespace”.  We need to have a use case where they may be allowed.  If Tony is going to try and get this into the v3 vocabulary, then we have no other use case at this time.  We may want to add extension without any use cases—lots of IETF protocols do that—but we don’t have a use case now.  However, creative authors have shown a history of extensions being added and useful to specific working groups.  That’s a good enough reason to say extensions are allowed.  Julian will write something.  Paul suggests adding a bullet point where there is a mode that you can find out what extensions you have at any given moment, so authors can double-check their own document.


2. Draft status

- plain-text

Waiting for feedback from the design team, then I’ll post.  In particular I’m looking for things that need to be fleshed out before coding can start.

- framework

Waiting for feedback from the design team, then I’ll post.  In particular I’m looking for things that need to be fleshed out before coding can start.

- non-ASCII

I’m holding off updating this one; the font question actually impacts this draft fairly significantly.  I don’t think just romanization is the right choice here, but recognize it may be our only choice for the immediate future depending on what fonts we can find and license that allow for non-roman scripts.

- HTML

- PDF

No update from Tony

- XML v3

The final thing in the v3 draft and the examples draft are all we’re waiting for at this point?  Paul has pushed out an update yesterday, and at this point it is up to date with everything we know about today.  It is now at small incremental improvements.

Summary of where we are with the various examples draft?

- Tony has updated the converter to -13, but hasn’t pushed it out anywhere.  Tony and Paul need to talk a bit more, and probably Paul will push harder to get the examples draft a little bit further forward.  Calendar milestones would be really helpful.

3. AOB

* Should we have a call 30 December?  Else, next call would be 13 January 2015.  We will just rejigger the call to restart biweekly the first week of January

* spaces after a period

Would like to solidly state that this is in the Style Guide (which it is).  What will this look like in the HTML?  HTML doesn’t treat whitespace as significant, and would have it all be a single space after a period.  A suggestion is to say that for variable-width text, let it figure out what happens after a period.  But that still won’t help with the mono-space sentences within a text. XML input in things that are free-text will have this problem regardless of font.
RSE Wiki Archive

User Tools

Site Tools

Page Tools
