Sunday, December 21, 2014

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/ ). PAM (which I hate), apparently however stats /etc/environment. Plenty more can be read here.

$ locale
Or, one by one...
$ echo $LANG
$ echo $LC_CTYPE
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"

Monday, December 15, 2014

[solved] "disabled" printers in cups, "rendering complete" PT II

With an HP printer, if you click "print", but have left anything disconnected... you're going to get pissed. CUPS should simply print the job once the printer cable is reconnected. But instead of helpfully printing, CUPS is much more likely to invoke TWO horrible-to-undo factors... simultaneously.
  1. CUPS invokes a "disabled" status for the printer and does not reveal this. When you reconnect the printer, the document does not print, but the icon will only (unhelpfully) indicate "rendering complete" with a green "pause" status for the printer.
  2. You'll think, "I just need to delete the document and try again now that the cable is connected". YES, you'll have to delete the document from the queue or the problem can't be fixed. (Use lpstat -o to get the job number and then cancel [job number] to eliminate it from the queue). NO, the problem is not yet fixed, and if you try to print again, you need to delete those attempts as well. Delete all print jobs and re-enable the printer using one of the two options below.

option 1 (5 minutes)

If a person is extremely fortunate, CUPS was installed with CUPS-specific permissions and group categories aligned. There are three layers to these, the first layer being correct permissions for loopback/localhost. Users can check this by attempting to access the CUPS browser-based administration page, running out of port 631, ie, http://localhost:631/. If that works, attempt to clear the disabled printer status as follows.
  • Find your paused printer and click on it.
  • Under the "maintenance" options for that printer, click on "resume". This is what re-enables the printer.
  • Authenticate to activate changes. Typically the user is "root" and then root's password.
At this stage, printing should work again. If authentication failed, either skip to Option 2 below, or take the time* to untangle the group/member permissions (these are the second and third layers of CUPS configuration -- see "cups printer permissions" below) and then go back to the CUPS administration page, once complete.

*an entire afternoon

option 2 (15 minutes)

Remove and reinstall your printer, which hopefully is not an HP. Find your USB port for the printer (lsusb) and then, eg...
# lpadmin -x Officejet_Pro_8500_A910 $ hp-setup -i --auto 001:004
If not an HP printer, then you will likely never have this "disabled" printer problem, but if you do have to reinstall a non HP printer, then the easiest way I've found is, eg...
# lpadmin -x Brother # lpadmin -p Brother -E -v usb:/dev/usb/lp0 -m brother.ppd


  1. Cancel all print jobs. The fix might work without this, but it's unlikely. Find print job numbers using # lpstat -o and then # cancel [print number], one by one. You will see no change yet in the "rendering complete" status, but print jobs need to be cleared for the "rendering complete" status to subsequently be cleared.
  2. "resume" the printer in the CUPS browser interface (if available), or remove and reinstall the printer using the terminal. Either way, "rendering complete" should disappear at this step.
  3. Verify that CUPS changes have succeeded by attempting to print or, in a terminal, type "lpstat -p": the printer name should be there and have a status of "idle".

cups printer permissions (in progress)

Users will often only learn their CUPS configuration is misaligned when CUPS authentication fails at the final step of a long process that otherwise seemed to be successful. Any or all of the layers below can be the cause of the problem. Layer 1: loopback/localhost Sadly, CUPS is a network, not a standalone, print server. This means one must disable a percentage of their loopback protections if they want to use CUPS and the CUPS administration page. Outrageous, but true. Loopback is not dealt with on this page. Layer 2: groups
Layer 3: permissions Layer 4: /etc/cups/cups.conf (not always) Most times, nothing needs to be done to this file. When it does, the most typical adjustment involves.

x crashes, video crashes, mouse crashes, kernel panics

A friend has an old HP box that was running Arch. He was experiencing system lock-ups using Wikimapia in concert with Google Maps in a browser. These programs paint a lot of polygons when scrolling and the kernel panics seemed to show memory leaks or other unauthorized writing to the drive. The failures were to varieties: 1) lockups, and 2) exit to terminal with kernel panics. Some possibilities:
  1. xorg setting for video card
  2. xorg setting for mouse
  3. browser leaks with multiple many-polygon pages open (maps)
  4. the old Intel 82G33/G31 integrated controller card being overwhelmed
  5. ?


We're looking for two main log types: Xorg crashes, and Kernel crashes. Xorg is the easiest -- hasn't changed much over the years. We can still find Xorg logs in /var/log/Xorg.0.log.old and copy to our user directory to read them in any text editor. Failures stand out, and there is usually enough information to start modifying one's xorg.conf file to fix whatever's wrong. In the case of my friend, it appears there was nothing failing and writing to Xorg.log, at least on a first-look.

Kernel crashes. During crashes, writing can be inconsistent; we can't be certain we'll have information. Additionally, journald crash logs are written in binary and, further, compressed, and so require the journalctl client to read whatever's in there (and of course "whatever's in there" can become corrupted during a panic). So it's 50-50 if we can see anything in these logs. IMO, verifying a corruption-free log is the place to begin.
# journalctl --verify the case of my friend's logs, this revealed a plethora of corruptions at times I could not decipher, but may have corresponded to the panics.

Given all of this, it appeared the best thing to do was get some text readable log information.
# nano /etc/systemd/journald.conf
ForwardToSyslog=yes crash, I should be able to see if there's anything out there in human readable text. Meanwhile...
# journalctl -b
... and look for errata.

video card

On the video card front, his old Intel 82G33/G31 is onboard and shares memory (fatal), but also appears to have some VRAM. No GPU.

Friday, December 5, 2014

[solved] (kinda) magical cups disappearance

Edit: I eventually rebooted after the CUPS reinstall and ran
# systemctl list-unit-files |grep cups
This time, and I'm not sure why, CUPS units appeared. One unit was org.cups.cupsd.service. Of course! A more complicated name for the service... how could I not guess this? So now, instead of the simpler...
# systemctl start cups
...we now have the impossible to remember...
# systemctl start org.cups.cupsd.service
...thanks a million, CUPS team. More keystrokes and slips of paper, perhaps that's the Linux legacy. At least this one is solved for now.

Edit 2: Evince not printing. Everything appears fine, but only blank pages result. Check it with a direct print. First command to get a list of the printer names, second command to directly print the file. In this case, suppose the name of the printer is "Foo", and the file to be printed is "somefile.pdf"...
# lpstat -p
# lp -d Foo somefile.pdf
If it prints this way, but not in Evince, it's got the f*cking bug.

I recently (12/5/2014) updated Arch and CUPS disappeared. It wasn't even there in the list of units. I ran...
# systemctl list-unit-files |grep -i cups
...which is just the CUPS scheduler, so no printers appeared. (The reason to use list-unit-files is it reveals any units, enabled or disabled). A check with
# pacman -Ss cups
showed cups was already installed. I reinstalled it, but still no appearance in the systemd list. Hmmm...

startup service

Then I recalled I'd made a custom startup service to remove the realtek module so it wouldn't continue sending errors. Could this be the problem?
# cat /etc/systemd/system/foostartup.service
Description=startup actions

ExecStart=/usr/bin/sleep 10s
ExecStart=/usr/bin/rmmod ums_realtek

But no, there was nothing in there which would effect CUPS.