[css-page] <page-size> Keywords #328
Comments
As for version 2016.7, Vivliostyle supports all the page sizes specified in the spec (and only these):
I believe the spec is clear that all formats are defined in portrait orientation, and Vivliostyle's implementation conforms to that.
I don't think I'd be in favor of this approach. It makes it possible to specify paper sizes that don't actually exist ( As for including more paper sizes in the spec, it is very cheap to implemented and there may be occasional demand, so we wouldn't be opposed to it, but it is also very easy for authors to work with actual dimensions if they don't have the keywords, so the need isn't that pressing either. We have yet to feel market pressure in supporting these other sizes, but if/when we do, we'll be sure to report back to the CSSWG. It was different for JIS-B5 and JIS-B4, since there's more demand for these than for the unprefixed (implying ISO) B5 and B4, so adding there helped alleviate some confusion. |
|
We produce many hundreds of books per year using Prince. Essentially none of them use any of the page sizes listed in any comment above. It's so very easy to type |
|
Correct me if I’m wrong, @dauwhe, but book sizes are much less standardized than loose sizes and they tend to use round values (or vulgar fractions with inches). The ISO (and JIS) sizes, on the other hand, have awful numbers to remember, because they’re designed to keep the same, irrational aspect ratio, so keywords are very useful for them. |
|
@Crissov agreed that keywords for ISO/JIS are important; I think they're less important for foolscap-quarto and friends :) |
|
I agree that Prince’s keywords in the last table should not be included in the specification. I’m somewhat growing fond of the Personally, I don’t care whether |
|
Based on the discussion here, it seems like nothing is urgent to add other than JIS-B4 and JIS-B5, which have been added already. I agree with Florian that unless there is specific demand for certain keywords, we should not add them pre-emptively. Therefore closing this issue. |
|
For the record, Shinyu Murakami writes:
And I'm inclined to defer to his position. |
|
I can live with However, @frivoal and @frivoal actually (also) wrote: “it is very cheap to implemented and there may be occasional demand” and “keywords for ISO/JIS are important”. The dimensions of an ID-1 business card or an A6 postcard are not easier to remember than of either of the B4s. It’s actually hard to remember which standard sizes out of the ISO series do have a keyword, although they are of course the most frequent physical sheet formats used for office printing. It’s different for inch-based sizes without √2 aspect ratio. Why should authors be bothered with looking up or remembering the dimensions of standardized sizes? CSS code also becomes more readable to future editors with keywords. As shown in the tables, there are interoperable implementations of additional keywords |
|
This is your annual reminder that keywords for the international standard sizes with an aspect ratio of the square root of two make absolute sense, i.e. everything from |
|
I think that there's a demand problem. While this not particularly hard to add, it still needs to be specified, tested, implemented across the board, etc. So that's still a non zero effort across for many different groups. I expect that people printing outside of the A3 - A5 range actually know how big their paper is, usually, and that the pain may be very limited for them. If browsers add support for these, adding them to the specification will be fairly trivial. But the hard part is convincing browsers individually that this is worth doing, and putting it in the spec does very little to that end, especially since what these should do is fully obvious. I suggest you go open bugs on individual browsers, rally around developers wanting these to vote these up, and generally work at making the demand for this feature more visible. That will have a much better chance at making it happen than pinging this group. |
|
I always considered CSS to be driven by specifications not by implementations, i.e. W3C invents something, then asks vendors to implement it and if they don't, drops it. My general experience with asking vendors to implement something that is consistent with a standard but goes beyond its actual prose has been that they simply reject it because it is not required or recommended by the standard. Standardization can be the act of documenting and harmonizing common practices to ensure interoperability, but this descriptive approach usually doesn't work well for web standards (although it has to be done like that frequently). |
Nope, the W3C is vendors (plus some subject-matter experts). While ideas can come from many sources (sometimes coming from browsers, sometimes from experts, sometimes from the community), ultimately a healthy standard is one that proceeds with vendor support thru its entire lifecycle. The "spec first, hope that someone implements it someday" model doesn't work very well, as we've rediscovered repeatedly thruout history. (This is why I keep my own "hopefully somebody wants to implement it someday" specs on my own GH repo; they don't get put into the CSSWG repo until someone wants to implement it and the group approves of it.)
Florian wasn't saying you should ask browser vendors to implement these new values unilaterally, but rather to get someone there interested in the feature, so that they'd be willing to implement it if it were standardized. Browsers are generally, rightfully, loathe to just unilaterally implement something.
Correct, "cleaning up afterwards" is a useful thing for standards to do, but not the only thing. But forging too far ahead is a different failure mode, one which is way too easy to fall into. Thus our general policy these days of getting as least some interest from browser vendors in a topic before pursuing it. |
|
I have documented interest in keywords for ISO paper sizes by some vendors in the initial message of this thread. Naturally, the interest is much stronger in print-centric products like Prince and AHF, while the large browser vendors with their screen-centric products do not care as much. Why does that not proof enough demand already? Since even browsers already support the limited set of standardized keywords, I believe that the cost of implementing the rest of the set would actually be negligible compared to the cost of arguing over their inclusion in the standard. 😉 |
TL;DR: Change
JIS-B5andJIS-B4toJIS B5andJIS B4.In November 2015 it has been discussed whether to include several additional page size keywords into CSS Page. Subsequently, Japanese
JIS-B4andJIS-B5have been added. They had already been supported by Antenna House Formatter due to strong local demand.Prince and Antenna House actually both support additional keywords, but with inconsistencies. I didn’t find relevant documentation for Weasyprint and Vivliostyle. I quote the tables below, but I actually wonder if CSS can learn from these and do better.
autois currently UA-dependent, but maybe it could be specified as defaulting to – if included –PA4, the (rounded) intersection of ISOA4and ANSI A (better known as USLetter): 210mm × 280mm.Most paper sizes for printers are specified with default
portraitorientation, i.e. smaller size first, and<length>{1,2}has width first and optional height second. Some sizes are primarily used inlandscapeorientation and therefore they have been implemented with large size first:id-1,id-2,id-3andledger. Except for the first one, which is the common size of plastic cards (at2.125in 3.37in), they are landscape aliases of other sizes:A7,A6andtabloid, respectively. Sinceledger(nottabloid) is currently specified as a portrait format, it should be clarified whether the implementations (intentionally) are non-comformant there and if it’s a bug in the spec.International paper sizes
The ISO sizes – series A and B defined in ISO 216 and series C in ISO 269 – have been adopted by many national standardization bodies. Some have extended definitions for special purposes, e.g. the RA series from ISO 217, German DIN 2A0 or the Swedish SIS D–G series and, of course, the Japanese B series (JIS P 0138). Most of them are of limited interest to CSS authors, at least with consumer printers.
A10C10B10A9C9B9A8C8B8A7,ID-2C7B7,ID-3A6A6C6ISO-C6B6ISO-B6,B6JIS-B6A5A5A5C5ISO-C5B5B5ISO-B5,B5JIS-B5JIS-B5A4A4A4C4ISO-C4B4B4ISO-B4,B4JIS-B4JIS-B4A3A3A3C3ISO-C3B3A2C2B2A1C1B1A0C0B0I believe it could be beneficial to have
<paper-size>accept two keywords, an optional one for the system (e.g.JIS) and a mandatory one for the size (e.g.B4).standard|auto(default, depends on the size)iso|internationallocaljis|japan|japaneseansi|us|america|american|archOne question is whether
iso legalandinternational letterwould compute toA4andUS A4toletter.Another question is whether UAs with local settings for Japan should equal
standard B4toJIS B4.Other metric paper sizes
ID-1HagakiISO-DLFolioA4cut toletterheight orlettercut toA4width (ifletterequalled P4 instead of ANSI-A).FolioisUS-Foliocut toA4width and Wikipedia has it under the lemma F4. ISO 217 RA4 is, probably by coincidence, roughly 8.5in × 12in, i.e. betweenletterandlegalorfolio/us-folio.letteror ANSI A.American standard paper sizes
US-StatementStatementUS-ExecutiveExecutiveUS-GovernmentGovernment-LetterletterUS-Letter,ansi-aLetterUS-FoliolegalUS-LegalLegalarch-aledgerUS-Ledger,ansi-bLedgerUS-TabloidTabloidarch-bansi-cCarch-cansi-dDarch-darch-e1ansi-eEarch-earch()could be defined as rounding up both sides to the next multiple of6in, or of3infor measures smaller than, say,10in.Other American paper sizes
The sizes
foolscap,crown,demy,royal,imperialcome in three variants each:octavohas the longer side ofquartohalved andfoliohas its shorter side doubled. Two of these could be implemented as functions or modifier keywords for all paper sizes, so that eitherquarto(A4)would equalA5or thatoctavo A5wasA7.halfandquartershould work equally well (with a respective note on traditional terminology) and thendoubleorquad/quadruplewould also be possible, but maybe that’s not worth the hassle at all.I’m not sure I like the alternative idea of
folio(A4, 0.5)=A3,folio(A4, 2)=A5and eitherfolio(A4, 3)orfolio(A4, 4)=A6. (Without the comma if you want and could be calledfold()instead.)foolscap-octavofoolscap-quartofoolscap-foliocrown-octavocrown-quartocrown-foliodemy-octavodemy-quartomedium-quartoroyal-octavoroyal-quartoroyal-folioimperial-octavoimperial-quartoimperial-folioThe text was updated successfully, but these errors were encountered: