DefaultPaperSize

Default Paper Size on Linux

In OpenOffice.org VCL has a concept of a default paper size for a printer, and most applications then have a parallel concept of a default paper size for pages in a documents.

The VCL paper size for a printer can be seen in the UI in file->printer settings->properties->paper size The Application paper size for a page can be seen in the UI in e.g. writer from format->page

The VCL paper size doesn't matter greatly as its overridden by most OpenOffice.org applications, only simple applications like Math have no page style to override it.

VCL Default Paper Size

On Linux this default paper size is determined in vcl/unx/source/printer/printerinfomanager.cxx as PrinterInfoManager::initSystemDefaultPaper

Application Default Paper Size

The default paper size is derived by SvxPaperInfo::GetDefaultPaperSize in svx/source/items/paperinf.cxx

GTK

For comparison gtk has gtk_paper_size_get_default which takes this from the locale as well, using gtk-mapping as a fallback when glibc's _NL_PAPER_WIDTH/_NL_PAPER_HEIGHT is not available (note that gtk only recognizes the A4 and Letter sizes from _NL_PAPER_WIDTH/_NL_PAPER_HEIGHT)

• LC_PAPER, LC_MESSAGES (gtk/gtkpapersize.c)

gtk mapping

All locales are A4 except for: en_US, en_CA, es_PR, es_US. See gnome#618000 to sync those defaults with this page and CLDR 1.8.1

Sources

Wikipedia currently states that the US and Canada officially don't use A4 but that in Argentina, Chile, Colombia, Mexico, Venezuela and the Philippines Letter is commonly used. Meanwhile at Microsoft the list of Letter nations is, the US, Canada, Argentina, Brazil, Chile, Mexico, Venezuela and "Latin American countries".

glibc

While glibc currently lists the US, Canada, Chile, Colombia, Costa Rica, Guatemala, Mexico, Puerto Rico, Venezuela and the Philippines as the Letter using territories. ([previously there were some oddities where en_US was Letter while es_US was A4, and en_CA was Letter while ik_CA and iu_CA were A4.

CLDR 1.6

At unicode.org the only locales that CLDR 1.6 listed as using Letter were the US and Canada.

CLDR 1.7

In CLDR 1.7 after cldr#1710), the Letter using locales were listed as the US, Canada, Chile, Colombia, Mexico, Puerto Rico, Venezuela and the Philippines.

CLDR 1.8.1

In CLDR 1.8.1 after cldr#2585 the Letter using locales are listed as the US, Canada, Belize, Chile, Colombia, Costa Rica, El Salvador, Guatemala, Mexico, Nicaragua, Panama, Puerto Rico, Venezula and the Philippines.

Summary

Mapping locales to page size was historically done inconsistently in OOo. Now we have one place that does it and reconciled the locales that have Letter as an appropriate default. The algorithm in use is that when taking a locale setting to use to look up a default paper size that we try through LC_PAPER first, using _NL_PAPER_WIDTH/_NL_PAPER_HEIGHT (as shown here), and then fallback to mapping a locale territory to a default according to best fallback mapping below in order of LC_ALL, LC_MESSAGES, LANG, en_US

paperconf's own default of using Letter as a final fallback sucks as most people use A4, ideally paperconf could be convinced to use the same mechanism in the absence of a override setting, which is what we now do in Fedora.

Probable Best Fallback Mapping

• United States (*_US), Letter : glibc agrees, CLDR 1.6 agreed, CLDR 1.7 agreed, CLDR 1.8.1 agrees
• Canada (*_CA), Letter : glibc agrees, CLDR 1.6 agreed, CLDR 1.7 agreed, CLDR 1.8.1 agrees
• Belize (*_BZ), Letter : glibc doesn't support this locale, CLDR 1.6 disagreed, CLDR 1.7 disagreed, CLDR 1.8.1 agrees. As a concrete example all the Belize Government Portal pdf forms are in Letter format.
• Chile (*_CL), Letter : glibc agrees, CLDR 1.6 disagreed, CLDR 1.7 agreed, CLDR 1.8.1 agrees
• Costa Rica (*_CR), Letter : glibc agrees, CLDR 1.6 disagreed, CLDR 1.7 disagreed, CLDR 1.8.1 agrees.
• Guatemala (*_GT), Letter : glibc agrees, CLDR 1.6 disagreed, CLDR 1.7 disagreed, CLDR 1.8.1 agrees
• Nicaragua (*_NI), Letter : glibc disagrees, CLDR 1.6 disagreed, CLDR 1.7 disagreed, CLDR 1.8.1 agrees. Most of the forms I see on the various .ni government sites are in A4 however. But according to cldr#2585 "There is no day to day use for A4 size"
• Panama (*_PA), Letter : glibc disagrees, CLDR 1.6 disagreed, CLDR 1.7 disagreed, CLDR 1.8.1 agrees. As a concrete example the medical forms at www.minsa.gob.pa, e.g. this form are in Letter format.
• Puerto Rico (*_PR), Letter : glibc agrees, CLDR 1.6 disagreed, CLDR 1.7 agreed, CLDR 1.8.1 agrees.
• El Salvador (*_SV), Letter : glibc disagrees, CLDR 1.6 disagreed, CLDR 1.7 agreed, CLDR 1.8.1 agrees. As a concrete example the 2009 Election Results are all in Letter format.
• Venezuela (*_VE, Letter : glibc agrees, CLDR 1.6 disagreed, CLDR 1.7 agreed, CLDR 1.8.1 agrees.
• Mexico (*_MX), Letter : glibc agrees, CLDR 1.6 disagreed, CLDR 1.7 agreed, CLDR 1.8.1 agrees.
• Colombia (*_CO), Letter : glibc agrees, CLDR 1.6. disagreed, CLDR 1.7 agreed, CLDR 1.8.1 agrees.
• Philippines (*_PH), Letter : glibc agrees, CLDR 1.6 disagreed, CLDR 1.7 agreed, CLDR 1.8.1 agrees). There is some ambivalence around whether Letter (known sometimes in The Philippines as "Short Bond Paper" ?) or A4 is the most suitable default. Some random blog comments suggest that Letter is still the most common paper. As a concrete example the Philippines Driving License form is in Letter size. See notes on the "Legal"/"Long Bond Paper" for other gotchas with Filipino paper sizes.

All others, A4 (including Brazil, Argentina)

Pulling PageSize from LC_PAPER

#include <stdio.h>
#include <locale.h>
#include <langinfo.h>

#define NL_PAPER_GET(x)         \
  ((union { char *string; unsigned int word; })nl_langinfo(x)).word

int main(int argc,char **argv)
{
  int w, h;

  setlocale (LC_PAPER, "");
  w = NL_PAPER_GET (_NL_PAPER_WIDTH);
  h = NL_PAPER_GET (_NL_PAPER_HEIGHT);
  printf ("height: %d\nwidth: %d\n", h, w);
  return 0;
}

This gives dimensions in rounded mm, e.g. with Letter getting recorded as 216mm x 279mm, while the accurate size of Letter is 215.9 × 279.4. So a conversion to rounded to whole mm is required to test for recognized page sizes.

Notes on Legal, Folio, German Legal Fanfold and Long Bond Paper

The Philippines has a paper size called "Long Bond Paper", also known locally as "Legal" which is 8.5" x 13". The same paper size is apparently known in some Latin American countries, e.g. Guatemala as Tamaño oficio or Oficio. The US Legal size is 8.5" x 14", causes confusion in at least the Philippines. 8.5" x 13" is called "German Legal Fanfold" in the PPD specification, but some e.g. Microsoft call that size "Folio". Unfortunately for the "Folio" term, in the PPD spec it is a different size than this (210mm x 220mm, i.e. 8.27" x 13"), and so is another ambivalent term probably best to be avoided.

Notes on Windows Paper Sizes

The Windows Documentation has some confusion around the two different JIS and ISO B paper types.

   DMPAPER_B4        B4 (JIS) 250 x 354 mm
   DMPAPER_B5        B5 (JIS) 182 x 257 mm
   DMPAPER_ISO_B4    B4 (ISO) 250 x 353 mm
   DMPAPER_B6_JIS    B6 (JIS) 128 x 182 mm

DMPAPER_B5 is documented as JIS and the documented dimensions match that format, but DMPAPER_B4 is then documented as JIS but the documented dimensions match the ISO format B5 of 250 × 353 mm. Given the presence of DMPAPER_ISO_B4 and the absence of DMPAPER_B4_JIS I'll bet that it is really the JIS size of 257 x 364, which is backed up by the PPD Specification stating that the Microsoft DMPAPER_B4 size is 257x364 and by the Microsoft Word UI which lists B4 (JIS) with a width of 257x364.

Since writing the above, the windows documentation has been refreshed and moved and now matches the above findings.

Meanwhile:

   DMPAPER_ENV_B4    Envelope B4 250 x 353 mm
   DMPAPER_ENV_B5    Envelope B5 176 x 250 mm
   DMPAPER_ENV_B6    Envelope B6 176 x 125 mm

suggest that for some special reason B6 Envelopes are rotated 90 degrees from B6 paper size (125 x 176mm) while the other B sizes when used as Envelopes are not rotated. This time the PPD Specification agrees with MS and gives

   EnvISOB4    250 x 353    DMPAPER_ENV_B4
   EnvISOB5    176 x 250    DMPAPER_ENV_B5
   EnvISOB6    176 x 125    DMPAPER_ENV_B6

in contrast to:

   ISOB4    250 x 353    DMPAPER_ISO_B4
   ISOB5    176 x 250
   ISOB6    125 x 176

DMPAPER_ENV_B6 doesn't matter so us, so lets just accept that it signifies an envelope that is the same size as a rotated B6 paper size.

Turning our eyes to the Excel Documentation we have more confusion with the XlPaperSize enumation. Here we have...

   xlPaperA5    A5 (148 mm x 210 mm)
   xlPaperB4    B4 (250 mm x 354 mm)
   xlPaperB5    A5 (148 mm x 210 mm)

well what size is xlPaperB5 ? Is it truly ISO A5 (148 mm x 210 mm) like the comment says. Or might it be ISO B5, i.e. 176 × 250 mm. Or, seeing as the XlPaperSize enumeration has the same values as the DMPAPER values for all other values, are they actually the same values as DMPAPER_B4 and DMPAPER_B5, which we've earlier determined are JIS B4 and B5 sizes, and not ISO sizes at all. That's the most likely answer, i.e. the text is completely and totally wrong.

Notes on Kai Paper Sizes

For some reason in OOo we have inherited from the past (they were there in the original cvs checkin) three "Kai" sizes. Stated originally in paperinf.hxx as...

   Kai16       (10433 twips x 14742 twips) // 16 kai 18,4 cm x 26 cm
   Kai32       (7371 twips x 10433 twips)  // 32 kai 13 cm x 18,4 cm
   Kai32Big    (7938 twips x 11510 twips)  // 32 kai gross 14 cm x 20,3 cm

A twip is a TWentyInPoint, where a Point is 1/72 of a inch, i.e. 1440 twips in an inch. The above twips seem to be been generated from taking the cm values and multiplying by the rather inaccurate 567twips per cm and rounding the result. i.e. the base unit of the calculation is the cm values in the comments.

This documentation states their sizes as

   16 Kai      (184 mm x 260 mm)
   32 Kai      (130 mm x 184 mm)
   Big 32 Kai  (140 mm x 203 mm)

Which tallies with the sizes used above.

But (at the time of writing, 2009-06-11) the Papierformat de.wikipedia claims

   Kai 8       (260 mm x 370 mm)
   Kai 16      (185 mm x 260 mm)
   Kai 32      (130 mm x 185 mm)
   Kai 32 groß (140 mm x 203 mm)

As does this page

   Kai 8        (260 mm x 370 mm)
   Kai 16       (185 mm x 260 mm)
   Kai 32       (130 mm x 185 mm)
   Kai 32 (big) (140 mm x 203 mm)

And this Konica Minolta magicolor 7450 printer technical guide also gives

   Kai 16      (185 mm x 260 mm)
   Kai 32      (130 mm x 185 mm)

There are other sizes listed as well in various places, e.g. 195 mm x 271 mm etc. So its all a bit confusing, and I'm not the first one to think so.

Kai is probably the transliteration of 开 and is probably just a generic term for a portion, i.e. a 16开 is 1/16 of a master sheet, and depending on the size of the master sheet that its cut from and the edge trimming used, a 16开 differs in size.

e.g. this page here where depending on the size of the master sheet, a 1/16 differs, as one example taking a master sheet of the paper-roll manufacturer size of 787 mmm × 1092 mm sheet (and the original native units here for the sheet in the cutting machine are more than likely 31 inch by 43 inches, converted to mm) then they cut a 1/16 sheet from this as a 16开 195 mm × 271 mm. Different size sheets, different trimming values => different sizes for a 开

So, given that we have a Kai 16 size in OOo and are probably stuck with it, should it be 184 mm or 185 mm in width...

1. This article is probably the most translatable of them, it contains the classic pile of near random different numbers, 184 mm, 185 mm, 195 mm etc. But helpfully heads off the page with "The common size are 8 开: 368 x 260; 16 开: 260 x 184; 32 开: 184 x 130"
2. This complaint says the Chinese version of Microsoft Word uses 184 mm for 16开 (His office has a 195 mm x 270 mm 16开 variety)
3. This this third hand report that 184 mm was physically written on the box of paper

I reckon we should stick with 184 mm as the canonical value for the "Kai 16" paper size that we've got, rather than change it to 185 mm