Worthy Pdf readers in Linix Mint/Ubuntu

There are plenty of questions on the Internet asking whether there are any PDF Readers (free of course) for Linux that have more capability than the one that is packaged with Ubuntu/Mint, the Evince, that allow the users to annotate and highlight the materials.

Adobe Reader 9 can do this provided that the document contains a policy allowing the users to comment and annotate. In the absence of such a policy, this reader defaults to denying such capability.

There does not appear to be any native Linux PDF readers that can do this. Some such as Okular can do highlighting etc but they are stored in their private format that only the viewer that created it could display them. Hence their annotations are not shown in say Adobe Reader. Therefore this class of viewers are considered not supporting the annotation and highlighting requirements.

As a last resort, I am using 2 Windows PDF viewers running in WINE in Mint/Ubuntu. They are PDF XChange Viewer and FoxIt Reader.

At the time of writing, I have uninstalled "PDF XChange Viewer" because in Mint-64 bit, it consistently crashed the reader when I was switching documents in the tabbed view of the reader. My experience is also supported by reported behaviour in the WineHQ. It is ashamed that it misbehaves in this manner. The other problem with this is with the display when scrolling the document. However, one can alter the display settings to prevent this.

While FoxIt Reader also has a native Linux version, it is a very basic reader similar to Evince that does not do annotation and highlighting. Consequently, this is not used. Instead FoxIt Reader version 6.1.2.1224 is installed with the support of WINE.

So far, it behaves well with the only exception that it fails to account for the height of the task bar in Mint when one maximizes the FoxIt window. As result, the navigation bar is partially covered.

The other issue which may unsettle some is the automatic installation and activation of the FoxIt cloud plug-in and the Reader does not have an easy way to uninstall this plug-in.

To disable this plug-in, close the FoxIt Reader and use the following steps in Mint/Ubuntu:
1) Bring up the File explorer, Nemo or Nautilus
2) Press Ctrl-H to view hidden file
3) Locate the Windows system tools in WINE installed directory which is by default located here:
~/.wine/drive_c/windows/system32
4) Then use the "Wine Windows program loader" to load Control.exe, the Windows control panel program and you should see a window like this:

5) Double click on "Add/Remove Programs" to start the program.
6) Locate the item called "Foxit Cloud" and uninstall that program item.

Next time you start FoxIt Reader, you will not see the "FoxIt Cloud" menu item. I only wish FoxIt would offer a more user-friendly way to disable it and also seek user's consent before activating the plug-in and FoxIt cloud.

Common reasons in software system failure

A post by Charette in IEEE Spectrum on the failure of various government systems sums up pretty much the general reasons why they fail:

put all the blame for the fiasco on Deloitte, which Deloitte heatedly contests. News reports state that at least one Florida lawmaker is suggesting that Deloitte be barred from future Florida contracts, something that Australia’s Queensland government has done to IBM as a result of Big Blue's role in the Queensland Health payroll debacle.
[...]
The bottom line was that no one was in charge, vendors and the state did not get along, the vendors themselves did not get along, no one wanted to hear about the myriad significant technical risks, and political motivations dominated decision making. In other words, all the makings of an all-too-typical government IT project.

Could it be that we are trying to develop software to do far more complex stuff, instead of being a tool to help human, they are being developed to replace human? In many of these systems, the common theme in all these failures - hire more human to remedy the failure!

In most of these large systems development, by the time the system is ready, the world has changed; the political scene has changed causing requirements to change; rules are changing all the time before the ink is dried.

Do not accept answers that you do not understand.

Not only it is the duty of the purse string holders needing to know precisely, without being clouded by technical jargon, what a software solution can do for the enterprise, every users need to know. This ensure that the buyers and users know precisely what they are getting and what they are paying for.

It is refreshing to come across this article in Financial Times relaying the experience of a very wise and persistent director of an enterprise that "demanded the computing experts translate their plans into plain English."

Far too often, as I have observed, that the recipients of software products choose to keep quiet for fear of showing up their ignorance or failure to comprehend of the materials from the so-called "technical experts". They all should emulate this "Dennis".

In fact, it is the communication fault of the "technical experts" that fail to explain the materials, particularly the functional part, in the terms that the users can understand. I don't expect them to explain how data base schemas are designed, XML messages being passed around or how to pool connections but at least they should be able to answer user-centric questions like what is the response time of say 20,000 users accessing the system, the stability of the system in terms of how often one expects a failure.

In a theme similar to the "Why Software Sucks" but at a different level, the  messages from the FT article are worth remembering. Admitting one does not understand the gobbledegook, often silently, and then not demanding answers to one's satisfaction is an abdication of one's duty.

Caveats in using GnuCash - Time Zone dependent

For anyone that uses GnuCash to manage an account and then making this account available to someone in a different country (more correctly different time zone), you need to be aware of the treatment of transaction date in GnuCash as it can cause disagreement.

Or for traveller that takes their account on a trip and diligently changing the time zone on arrival of each location and then recording transaction en route. For example, if you travel from NYC and visit HK record a transaction, and return to NYC, GnuCash will render the transaction date for the HK transaction differently when viewed in NYC.

To understand this time zone dependency one needs to understand how GnuCash records the transaction date, which is stored in transactions.post_date.

GnuCash stores each transaction date (entered in local date) in UTC by converting the local date you enter taken as at 0000 hour using the system time zone and it does not stores the time zone information of the transaction date. But GnuCash always displays the transaction date in local date by conversion using the system time zone. If the transaction journals contain records recorded in different time zones, the user can be confused when viewing these transactions.

Recently I ran into a problem when I was reconstructing an account from a pile of statements from Hong Kong. I was entering the transactions, whose dates were clearly in Hong Kong Time zone using Brisbane Time zone (UTC+10) unaware of the conversion mechanism underneath.

When the GnuCash account was then shown in Hong Kong, after changing the system time zone to that of Hong Kong (UTC+8), all the transaction dates were one date behind even though the time zone difference was only 2 hours difference. How could this small change resulted in a 24 hours shift?

It turns out GnuCash drops the time when rendering the transaction date. Hence a transaction date of May 23, 2012 (at 0000) in Brisbane Time Zone recorded as 20120522140000 is converted to Hong Kong Time zone as 22/05/2012 2200 and displayed as 22/05/2012 after discarding the time.

Because GnuCash always uses 0000 hours on recording and then dropping the time after converting to local date/time, this can give an incorrect date, like a 24 hours shift.

For some other time zone difference the change does not yield any difference. It all depends on the shift.

This date treatment means:
1) that the database of GnuCash is tightly dependent on the time zone and one is ill-advised to change the system time zone. If you move domicile, you may have to create a brand new GnuCash database for that new time zone.

2) If dispatching the database to a different time zone, warn them conversion may alter the transaction date.

One size does not fit - Windows 8.1 upgrade

It appears Microsoft has not learned that one-size does not fit all when designing Windows 8 to replace Windows 7. The comments from this article <http://www.theregister.co.uk/2013/09/12/windows_eight_one_review> puts it succinctly the difficulties Microsoft is facing inflicted by herself:

The Search app also deserves a mention. Search “Everywhere” from the Charms menu, and an app pieces together local and web results into a multimedia view that works brilliantly for certain types of search. It is an excellent app. The question is: will users who are stuck in the desktop ever discover it? That question expresses Microsoft’s difficulty. The more it steers users towards the Windows 8 tablet platform, the more complaints it gets from bemused and often conservative Windows users. The more it enables user to stay in the desktop environment, the harder it becomes to establish its new app platform.

I honestly don't understand why Microsoft is hell-bend on subscribing to this silly idea that there is only one way to use a computing device. The only conclusion is to use a force users to use the "Modern" (aka Metro) apps so that their effort will quickly boost up the number to compete with Apple and Google. In order words, Microsoft is using her customers as their foot soldiers.

Apple seems to understand this issue much better than Microsoft and handles the situation with finesse. Apple does not try to make MacOS to run and behave like iOS. This is not only sensible but free each group of designers the constraint one form of device would impose on the other learning to all sort of ridiculous compromises.

Microsoft appears to be incapable of learning from its past. When Microsoft brought out the PDA (Personal Digital Assistant), a fore-father of today's smart phone, it tried to make its operating system emulating the Windows' and this exercise failed miserably.

Now Microsoft is contended on forcing Desktop user to run like a 9-10" touch devices when they do not have any touch facility. Surely with the kind of resources available in Microsoft, they can build into the Windows the intelligence to detect the operating hardware and to be adaptive.

As a concession to Desktop user with 19+" monitors, Windows 8.1 now allows user to resize their "Modern" apps. 

I actually find this term "Modern" user interface kind of inappropriate. What is so 'modern' when you look at one, it reminds one of the good old dumb terminal display - always fixed at that size (80x24) - except that this now has color and gaphics. Nevertheless, it is fixed and can't be resized, except in Windows 8.1. All controls are flat ugly as compared to those in Windows 7, even without Aero, and lacking any feedback. In many applications one can't tell if it is a clickable control or just a piece of text. Calling that 'Modern'? Please bring back the ancient user interface.

Comments and Caveats in using Portable GPG Shell - gpg4usb

At the on set, let's me congratulate the developers in Gpg4Usb for releasing a very useful GPG shell that is portable in Windows and portable in a sense in Linux. The same distribution can run in Windows and in Linux, with some caveats as discussed below.

You can download a copy from here and unzipping it into a folder in Windows or Linux and you can immediately use it by running the program start_windows.exe. In Linux, you start the program by launching the start_linux program.

While it cannot do all the stuff that Gpg4Win can do in Windows, the beauty of Gpg4Usb is that it is self-contain and can run off the USB drive in any Windows without Administrative Privilege. It carries a copy of gpg.exe for Windows and gpg for Linux in the bin folder. The keys, using the standard format used by gpg.exe, are kept in the keydb folder.

Since there is no special treatment needed to get this program running in Windows from your local hard drive or your USB drive, let's move the discussion onto running this from Linux.

Through no fault of this program if located on USB drive, the default way of mounting the USB drive in Linux forbids one to execute any binary from such a device. Hence it is not as portable as in a Windows environment where there is no such restriction.

Without root access, the only viable option is to copy the gpg4usb folder onto a local drive (into the home folder if you like) from the USB drive. If you have updated any keys while using this program directly from the USB drive in Windows, all you have to do is just to update the gpg4usb/keydb folder on your local drive. Once you have done that, the following caveats apply:

1) Make sure you change the file permission of the following files to have executable permission:
    gpg4usb/start_linux
    gpg4usb/bin/gpg

Failure to do so will not launch anything and there is no crash message. If you simply give gpp4usb/start_linux executable permission, in a 32-bit Linux, the program will start but you will not see the keys in the key store. This is because the program fails to launch gpg4usb/bin/gpg necessary to retrieve the keys.

2) In a 64-bit Linux you need to ensure that you have 32-bit binary support. In Debian/Ubuntu derivative distro, such as Mint, you need to use the Software Manager to install the package ia32-libs-multiarch.

Without that package the program will not start even if the Caveat 1) above has been applied. I would recommend to try to run the program after applying the changes mentioned in caveat 1) first just in case some other 32-bit program may have installed the 32-bit support for you.

This program, despite the above caveats in Linux, is a competent replacement of GPA that is not longer supported and even KGpg.

Caveat to customise Ubuntu locale for Ubuntu Thunderbird

Further to my post on how to customise the locale in Ubuntu and my suggestion to use the following format:
     xx_YY.CHARSET@extra

as a way to provide customised locale settings without replacing the system's.

Unfortunately, Ubuntu Thunderbird (ver 17.0.6) cannot handle the above mentioned convention even though Ubuntu can comfortably handling this.

By way of experimentation, I have discovered that it appears that Thunderbird picks up the local specifier in the LC_* environment variables and drops the part from @ onward and then using that as the locale specifier to load the locale settings.

So for example if you customise say English (Hong Kong) and name the customisation where you change the time/date format as en_HK@test and then you select this in your Regional Formats. When Thunderbird loads up, it will pick up the specifier en_HK.utf-8@test but it will only use en_HK.utf8 to load up the appropriate locale settings thus ignoring your customisation.

Hence if you want to correct the locale for Thunderbird, the only way is to replace the system file.