- - - By CrazyStat - - -

24. June 2014

Inkscape: Problem importing PDF

Filed under: Windows — Tags: , , , , , , , , — Christopher Kramer @ 18:39

I just had problems importing a PDF into Inkscape. The PDF was an image of a graph generated by igraph for R. When importing, the circles of the vertices got replaced by the letter “q”.

I found the following workaround: I printed the PDF into a new PDF using FreePDF. The resulting PDF could then be imported into Inkscape without problems.

My original problem was that I wanted to include the graphs from igraph for R in Powerpoint as a vector graphic. As Powerpoint cannot include PDFs as graphics, I wanted to save the graphs as emf-Files. But the emf-Files exported by igraph for R look completely messed up when imported in Powerpoint. The PDFs exported by igraph for R are fine, so I wanted to import them into Inkscape and save them as emf. A bit of a long way, but it works and it does not result in an ugly pixel graphic.

Maybe somebody has similar problems and finds this useful.


Try my Open Source PHP visitor analytics script CrazyStat.

16. May 2014

Inkscape: Dialog windows do not open on multi-screen setups

Filed under: Windows — Tags: , , , , , , — Christopher Kramer @ 17:06

I am using a multiscreen setup with one small landscape screen and one big portrait screen.

When I try to open a dialog like the Inkscape settings or the document settings in Inkscape, it does not open. Or more precisely, I cannot see it because it is positioned outside the visible area. I have this problem with current Inkscape 0.48.4 on Windows 7 Professional 64bit.

The bug is known for some time but unfortunately not fixed.

But I found a great and easy workaround which I want to share with you here: Whenever you cannot see a window because it is offscreen, press [Windows-Key] [arrow-up-key]. This shortcut maximizes the current window and you can use it normally. This probably only works on Windows 7 and newer.

You can also use the left or right arrow-key to position the window on the left or right half of the screen.

Happy drawing! πŸ™‚

11. December 2012

VIA VT6421 SATA RAID Controller: Hardware Initiate Failed (HDD)

Filed under: Uncategorized — Tags: , , , , , , , , , , , , , , — Christopher Kramer @ 21:24

My home-server’s motherboard is quite old and does not have onboard SATA. Therefore, when I bought a new hard drive for the server, I connected it to a PCI SATA controller card. Performance doesn’t matter much with this server (I am the only user, it mostly only runs cronjobs and the-like). The SATA card had a VIA VT6421 chip on it. From time to time, I had the problem that the computer wouldn’t boot failing with this error message:

Hardware Initiate failed. Please check Device.
The BIOS does not be installed. Press g to Continue.

Nice error message πŸ˜‰
If you google this, you’ll find lots of people with this problem.

When I pressed CTRL+ALT+DEL to reboot the pc, it always detected the drive then. On the internet I found out that the problem is caused by SATA 300 (3Gbit/s) hard drives attached to the VT6421, which only supports SATA 150 (1,5Gbit/s). The Samsung drive I had at this time (a Samsung F2 EcoGreen 1500GB HD154UI 5400/m) didn’t have a jumper to change to SATA 150 (like some drives have), but Samsung provided a bootable tool to change the speed setting of the drive. (Samsung does not produce hard drives any longer, so I couldn’t find the software on the Samsung site anymore. I have it burnt on a CD, though. Contact me in case Samsung doesn’t publish it any longer and you really need it.)

Using the tool with the Samsung drive didn’t really solve the problem for me. But as it only occurred from time to time, I did not invest any more time to solve the problem.

Then one day the Samsung drive died πŸ™ and I bought a new drive. This time it was a Seagate drive (Seagate 2000GB Barracuda Green ST2000DL003). With this drive, the problem occurred every time I booted the pc. As before, restarting the computer made it detect the drive, but it was very annoying. This drive has a jumper to set the speed to SATA 150. I inserted the jumper as described on the Seagate website (attention! look at the graphic twice because it is drawn upside-down!). The problem remained unchanged :(.

Finally, I found the solution to my problem while googling forums again. Somebody wrote that he could not make the SATA controller detect the drive since he disconnected the dvd drive (sorry I cannot give the link, I do not remember where I read it. Thanks a lot to the guy who wrote this nevertheless!). So I connected an unused dvd drive to the IDE port of the sata controller board (I did not use the IDE ports of the VT6421 card at all before, only the sata ports). And from now on, the controller detected the drive correctly! πŸ™‚

So the short story is: Connect some additional device like a dvd drive to the IDE port of the controller card to solve the SATA problem!
At lest it worked for me. Maybe you additionally need the jumper as well (I did not remove it).

Kind of weird. I guess detecting the IDE device makes the controller busy for a moment so the drive is ready once the controller tries to detect it. But that’s only guessing.

I hope this helps somebody with the same problem. Please share your experience in the comments if it helped you.

9. September 2012

Zimbra: Creating a new self-signed SSL certificate

Filed under: Linux,Server Administration — Tags: , , , , , , , , , — Christopher Kramer @ 10:04

I recently had to recreate the SSL certificate of a Zimbra server and surprisingly it was not as easy as the documentation looked like, so I’d like to document how it is done and make comments on some difficulties that might come up.

So this is how it is done (on a Ubuntu Server running Zimbra Network edition 6.0.16 GA):

  1. SSH into the server, login as root
  2. Switch to the zimbra-user using
    su - zimbra
  3. Then run the following commands:
     sudo /opt/zimbra/bin/zmcertmgr createca -new
     sudo /opt/zimbra/bin/zmcertmgr deployca
     sudo /opt/zimbra/bin/zmcertmgr deploycrt self
  4. Restart Zimbra. To do so, as user zimbra, issue these commands (no sudo here):
    /opt/zimbra/bin/zmcontrol stop
    /opt/zimbra/bin/zmcontrol start

So the difficulties I had and some remarks:

  • sudo kept asking me for a password when I typed in
    sudo zmcertmgr createca -new

    Seems I am not the only one with this problem. The zmcertmgr command is white-listed in /etc/sudoers so you should normally not be asked for a password. Run the following command to edit /etc/sudoers (do not edit it in any other way!)


    So make sure in this file the following line is included:

    %zimbra ALL=NOPASSWD:/opt/zimbra/bin/zmcertmgr

    The % at the beginning seems to belong there. Note that the zimbra wiki has typo (zmvertmgr) in this line.
    But although I had this line in there, sudo kept asking me for the password. So what finally worked was invoking zmcertmgr with the complete path (as done above).
    Update: It seems I had a typo in here myself. Make sure it is “zmcertmgr”Β  and not “zmzertmgr” πŸ˜‰
    Thanks to the comment by erolha!

  • In the Zimbra Release notes, the last command for updating the certificate is
    sudo zmcertmgr deploycrt self -new

    I got this error:

    Can't deploy cert for -new.  Unknown service.

    Without -new (and the complete path), it went through well.

  • No zimbra documentation I found mentions that a restart of zimbra is required, but without a restart, the old certificate was still used when opening the webmailer or the admin interface via https.


I hope I could help some of you that run into one of these problems.

9. June 2012

Typo3 and other charsets than UTF-8 (latin1 / ISO-8859-1, …)

Filed under: PHP,Server Administration,Typo3 — Tags: , , , , , , , — Christopher Kramer @ 12:30

When updating a Typo3 installation to Typo3 4.5.x, I had problems with charsets and explained the solution here.

Now updating an installation of Typo3 to 4.6.x, I ran into another charset problem: The backend now was completely UTF-8 and therefore, changing texts in the backend caused them to be stored as UTF-8. As the frontend was still ISO-8859-1, special characters (Umlaute) over there got messed up. Maybe there is a way out of this as well ($TYPO3_CONF_VARS['BE']['forceCharset'] I guess), but this clearly shows that Typo3-developers drop support for other charsets slowly and that it might be easier to switch to UTF-8.

In the release notes of Typo3 4.5, I found the following passage:

UTF8 by default: New installations will use UTF8 automatically. Keep in mind that we will be deprecating all other charsets in the release of 4.5, but still support those charsets. 4.7 or maybe even 4.6 will be the first “UTF-8 only” release. When upgrading from older releases to 4.5, you will have to specifically set $TYPO3_CONF_VARS['BE']['forceCharset'] and $TYPO3_CONF_VARS['BE']['setDBinit'] in your localconf.php. An Upgrade Wizard will help you with that.

In the release notes of Typo3 4.6, I could not find a word about UTF-8, but in the release notes of 4.7, it is clearly stated:

check you database if it is utf-8 encoded – TYPO3 4.7 only will work with utf-8.
The forceCharset option has been deprecated in version 4.5. UTF-8 is now enforced. Even though other values than “utf-8” have not been possible anymore for some time, the option’s value has been queried at plenty of places within the whole core. These references, the option in the Install Tool, as well as many defaults with charset β€œiso-8859-1” in several classes have been changed, so TYPO3 now works UTF-8-only internally.

So it is clearly time to make the switch.

It is not that complicated – everything is described very well over here.

As the official wiki is very long and explains lots of stuff you might just not care, here are the basic steps:

  • Backup Database and Files
  • Set the charset in your webserver (e.g. “AddDefaultCharset utf-8” in a .htaccess)
  • Adjust some settings in localconf.php:
    // For backend charset
     $TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
     $TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;'; 
     // For GIFBUILDER support
     // Set it to 'iconv' or 'mbstring'
     $TYPO3_CONF_VARS['SYS']['t3lib_cs_convMethod'] = 'mbstring';
     // For 'iconv' support you need at least PHP 5.
     $TYPO3_CONF_VARS['SYS']['t3lib_cs_utils'] = 'mbstring';
  • Adjust your typoScript (change language to your needs):
    config.locale_all = de_DE.utf-8
  • Convert your templatefiles to UTF-8 (and remap them if you use TemplaVoila) – usually in fileadmin/templates
  • Convert your DB to UTF-8
    1. Backup it first if you have not yet (believe me!)
    2. Paste this tool into fileadmin
    3. Run it by opening it in the browser (
    4. If everything says “OK”, change the constant “SIMULATE” to false
    5. Run it again
    6. Clean cache of Typo3
    7. Check your site (esp. special characters). If the content is messed up or parts are missing, do the following:
      1. Restore the backup of the database (yes, I told you!)
      2. Uncomment lines 108 – 123 in db_utf8_fix.php
      3. Run it in browser againClean cache in Typo3
    8. Clean all cache in Typo3 Backend

You can find more detailed information here. There are also lots of other ways described how to convert the database.

Happy converting!


Update 2014-05-05: Changed link to db_utf8_fix-script as the original site is reported to be attacked and does not host the script anymore. I cannot check if the script at snipplr is exactly the same, but it looks so.

14. February 2012

Horde language selection does not work

Filed under: Linux,Server Administration — Tags: , , , , , , , , — Christopher Kramer @ 13:22

When selecting a language at login, Horde webmailer does not change the language?

Here is what I found out what helps:

On Debian, run the following command:

dpkg-reconfigure locales

Then select the correct languages. I had only selected the UTF8 languages for German, but Horde needs the following ones:

de_DE ISO-8859-1
de_DE@euro ISO-8859-15

If you have the problem with another language, select the corresponding language.

On Ubuntu, the chosen languages are stored here:


I had a file named “de” in there where my chosen languages where listed and I added the ISO-versions above. You can find all supported languages here:

less /usr/share/i18n/SUPPORTED

On Ubuntu, after you included your languages, you have to run the following command:

dpkg-reconfigure locales

Afterwards, you need to restart apache:

apache2ctl -k graceful

That’s the smoothest way. In case it does not work, use one of those:

apache2ctl restart
service apache2 restart
/etc/init.d/apache2 restart

Now refresh Horde and everything should work.

Another problem is the following: if you chose a language in your Horde settings (login, Global Options, Locale and time, Select your preferred language), this overwrites the language you chose on login. So select “default” there to be able to chose language on login.

Hope this helps somebody.

12. January 2012

Typo3: Mailform charset problems after upgrade

Filed under: Typo3 — Tags: , , , , , , , — Christopher Kramer @ 14:22

After upgrading Typo3 from 4.1.6 all the way to 4.5.10, mails sent through the default Typo3 mailforms were messed up because the charset was wrong. The charset of the page was ISO-8859-1 consistently everywhere, but the Typo3 mailform expected input to be in UTF-8 and sent the mails as UTF-8 although the browser sent the dataΒ  encoded in ISO-8859-1.

After lots of things I tried, the following TypoScript fixed the problem. You simply put it into the TS of the Template.

page.config.formMailCharset= iso-8859-1

Of course you can put another charset in there if you have a similar problem with another charset.

It took me so long to find this out as the Typo3 code editor did not know the setting and it was not documented anywhere I looked at.

Maybe this helps somebody…