page size - chromium printing

Most federal and state tax instructions have, over the past 3 years, been transformed from PDF's into (unhelpful) web pages.

This means that citizen taxpayers must now themselves save instruction webpages to PDF. Once saved to PDF, citizens may again accomplish quick searches, print worksheets, or preserve the PDF as a record of the instructions they used that year.

Sounds quick, but not always: how the webpage is saved to PDF determines how it can be printed, and computer settings determine how the browser may save webpages. All together then, three additional failure possibilities have been added to tax preparation. Perhaps the idea is to encourage citizens to purchase parasitic 3rd party tax preparation.

chromium solution

Let's solve this browser PDF issue if we can, starting with Chromium. Chromium saves/converts webpages to PDF's in a default A4 paper size. But most US printers can only print to letter-size. Chromium, as installed, provides no method for changing the paper size of how a PDF is saved.

With a significant time investment, I was able to determine that Chromium relies upon the locale variable LC_PAPER for its PDF paper size setting. Now, locale variables are complicated multi-effect variables which one doesn't wish to risk modifying for a simple paper setting. I was unable to find any other way to proceed.

1a. in-session

The hack below has an immediate effect in Chromium, allowing one to select the type of paper on a drop-down, whereas there was previously no option to change paper.

# localectl set-locale LC_PAPER=en_US.UTF-8

1b. in-session

If the above doesn't work, it may be important to know that Chromium takes its settings from GTK2, variable GtkPaperSize, of which we would like to at least be able to change between letter and A4.

2. persistent configuration

In Arch, I found two files, depending on whether I wanted global settings or user settings. Both must be created and there's a skeleton in /etc/skel/.config/locale.conf

• user: ~/.config/locale.conf, which can be activated by logging out and then back in. However. whether or not Chromium bothers with user-level settings seems questionable.
• global: /etc/locale.conf.

good information on the subject.

• disable the LC_ALL and/or LC_CTYPE variables as they will override all subsequent individual variables such as paper size. But where? Arch prefers us to use locale-gen, which means uncommenting inside /etc/locale.gen. However, locale-gen sets monolithically: all variabless get the same value.

change what?

en_US

locale

Just as with the pernicious problem of pulseaudio, locale information is stored in several places and they need to be narrowed down to a single source. Further,they're exported to kernel as a group but we only want LC_PAPER to be corrected, otherwise we will have problems with fonts. Typically, they are held consistent across all variables.

/etc/locale /etc/profile.d/locale.sh
~/.config/locale.conf
/etc/environment (PAM only)
/

localectl

locale-gen

A worthless application. Causes problems familiar to the similarly abstracted GRUB configuration, once it began auto-generating. Locale-gen generates monolithic LC settings, not individual ones. No setting just one variable. Using # locale-gen after a user modifies /etc/locale.gen, it overwrites all the LC variables to one single language, so it's worthless attempting to just change paper size

Of particular note is users will be punished with A4 if they don't want to declare a locale, since declaring locales causes problems with various fonts..

Locale miasma

Linux has so many problems and so many solutions, but if you've been in it for years, two of the biggest little issues that turn into patience cancers are sound and locales. Note from this page the number of variables which can be accepted.

But there are memory (aka "speed") concerns involved with locale selection, which is why I typically only use "C", by uncommenting it inside /etc/locale.conf. To check:

$ locale
LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C

However, suppose I want to do something as simple as play solitare.

$ sol v=Klondike
Non UTF-8 locale (ANSI_X3.4-1968) is not supported!

What's needed is a fast way to switch locales, obviously, but without the downstream issues of perhaps font regeneration and other failures.

Medieval Cyrllic (aka "Old Church Slavonic", "Old Bulgarian") fonts in LibreOffice

The only way I've seen this work is to take the TTF fonts created for Microsoft Word and adapt them. LibreOffice appears to require not only the TTF files, but also the associated AFM and PFB files. These cannot be created perfectly, but with font-forge, it's possible to produce versions of AFM and PFB which are reasonably close.

1. Copy the TTF files into /home/foo/.fonts
2. Open one of the TTF's in Font Forge
3. Select "Generate Font", using the PFB option. An AFM will automatically be created
4. Make sure all three versions of the file, TTF, AFM, and PFB files are in the /home/foo/.fonts
5. Restart X
6. Open LibreOffice -- the font should be in the font list
7. Profit

locale issue

Full implementation of these fonts requires multi-byte encoding -- there are more than 256 glyphs available. This means of course dealing with locales. I don't like to use UTF-8 because, when encoding, it's inefficient. The best possible solution for a locale with these fonts appears to be "C". I checked my locale with the following (reports according to information in /etc/profile.d/locale.sh ). PAM (which I hate), apparently however stats /etc/environment. Plenty more can be read here.

$ locale
LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=

Or, one by one...

$ echo $LANG
C
$ echo $LC_CTYPE
C

The LC_ALL variable is one I've wanted to investigate more fully. For example, I was reading on Stack Exchange that LC_ALL can override the settings of the other variable settings.

manually updating locale variables
There are several programs which update locale settings. I prefer to hand edit configurations. The primary Arch file to customize these settings is /etc/locale.conf, which generally must be created. Other distros use /etc/default/locale. Alternatively, suppose I just wanted to set one or two of these variables? I'd likely export them to the kernel directly from ~.bashrc (as I do my TexLive path). Using LC_ALL as an example, and assuming a more intelligent user...

$ nano .bashrc
export LC_ALL="C"

Masochists or less intelligent users might want to use...

$ nano .bashrc
export LC_ALL="en_US.UTF-8"