The February 2007 Blog
send me a comment

Using Ghostscript to Reduce PDF Size (Thursday, Feb 22)
[ permalink ] [ e-mail me ] [ ]

I like Ghostscript (the PostScript to PDF converter). Part of it is because I have an innate affection towards command-line tools. And part of it is because GhostScript has an extremely impressive amount of features and options (I'm guessing around 200,000 features, although that could be a little high ;-).

A couple years ago, I wrote about how you can use GhostScript to convert PDFs to image files, which is handy if you want to create a thumbnail of a PDF for a webpage, or archive a PDF as a multi-page TIFF or something.

I also used it recently to dramatically shrink down the file size of a PDF I had generated with the CutePDF Writer PDF printer driver. The PDF I "printed" with CutePDF ended up being over 2 MB in size, which was way too big for me.

I did a little searching on the web and found that GhostScript (of course) can reduce the file size for me. Here's the command line:

gswin32c -sDEVICE=pdfwrite -dNOPAUSE -dBATCH -dPDFSETTINGS=/ebook -sOutputFile=C:\newFile.pdf C:\originalFile.pdf

That knocked the size down from about 2.5 MB to about 600 KB. Much better. Using "-dPDFSETTINGS=/screen" actually made the file a little smaller, but the graphics were noticibly fuzzier with "/screen" instead of "/ebook".

I'm not entirely sure where the size savings came from. There were several graphics in the PDF, so it might have just been an overall lowering of graphic resolution. In any case, it worked for me but your mileage may vary.

Wikipatterns and Social Software Adoption (Wednesday, Feb 21)
[ permalink ] [ e-mail me ] [ ]

Michael Sampson recently linked to an interesting site: the Atlassian Wikipatterns wiki. Interestingly, the word "Wikipatterns" is NOT in CamelCase.
;-)

Atlassian certainly knows a thing or two about wikis, so I'm looking forward to reading the different patterns on the site to see what their experience has been. So far, there are four categories of patterns:

It's also nice the way they have the comment system set up on the different pages, so people can discuss the topics (the "Using CamelCase" anti-pattern looks to be a potentially good discussion).

This also made me think of a blog entry that Luis Suarez linked to a few months ago: Management can kill a community of practice. It relates a story of how a grassroots knowledge management team at a company was nearly destroyed when the PHB's decided that they needed to "manage" the team to make sure it had proper structure and oversight.

That entry makes reference to an 2001 APQC report titled Building and Sustaining Communities of Practice that came to the same conclusion: "management can hamper or kill a community, but it cannot make it thrive”. I'm not interested in paying the $450 to read the report itself, but the Key Findings list (from the previous link to the report) and the Executive Summary provide some good insight into what the APQC people found.

Fast-forward from 2001 to 2007, and we can guess that we'll have similar issues pushing social software like blogs, wikis, and aggregators in corporate environments. As I've said before, Social Software is the new Knowledge Management. There are challenges involved with putting tools for user-driven content out on an intranet and then mandating that people use those tools. People don't work that way. They'll use the tools if they think they're interesting and useful (and maybe even fun), but not because their boss is breathing down their neck telling them to add content to this wiki or else.

In the end, the approach that companies take will make a huge difference in how these technologies are adopted. Top-down directives may not work so well, and upper management is going to have to make sure that people aren't punished for "playing around" with the new tools that they are given. Playing with the technology is ultimately what will make people realize that they can do something useful with it.

How Do ILUG Thee? Let Me Count The Ways (Monday, Feb 19)
[ permalink ] [ e-mail me ] [ ]

Paul and Bill have officially launched the ILUG 2007 site, so start making your plans now. Me and Rob will be revisiting our error trapping session at the event, and we're just a small part of a tremendous cast of speakers.

I'll probably be buying plane tickets this week. My wife and I are both heading out there for a little vacation on top of the conference. I think the way our schedule will end up is:

That seems like the best way to schedule it, if we can. Flight prices are a tiny bit cheaper flying back on Monday instead of Sunday, but not cheaper enough to make a big difference.

Anyway, it's going to be a great show and Paul and friends are putting a huge amount of effort into it, so try to make it if you can. If nothing else, it's a great excuse for a vacation.

Oh, and I hear that a couple of sponsor spots are still available if you're interested...

ODBC Calls Using LEI (Sunday, Feb 18)
[ permalink ] [ e-mail me ] [ ]

Bruce had an LS:DO problem recently and talked about potentially moving the code to LEI/LCLSX to see if that helped. Even though this isn't Thursday, I'll go ahead and post this as a Show 'n Tell Thursday tip for you.

Here's some code that shows you how to make an ODBC call using the LEI LCLSX classes in LotusScript:

Making calls to an ODBC DSN using LEI (also in prettified HTML format)

First of all, some terminology:

So... why use LEI and LCLSX instead of LS:DO? Well, to be honest I still go back and forth between the two. I've heard that LEI gives better performance when you use the native connectors, and if you add DECS to the mix you can do a lot of server-side configuration to simplify things. However, I've always found LS:DO a little easier to use, so I still fall back on that quite a bit.

In the example above, then, why would you want to use LEI to make ODBC calls, instead of LS:DO?

Not too long ago, good buddy Bruce was also having a problem accessing a WVARCHAR field using an ODBC driver and LS:DO. If he used the driver and a DSN to access the data with something like Microsoft Excel, everything came over just fine. But if he used the same driver and the same DSN with LS:DO, it didn't work. The WVARCHAR data was blank. Nothing there.

The "W" in WVARCHAR stands for "wide", which is another way of saying "Unicode" (not strictly, but pretty much). LS:DO was choking on the Unicode data, even though the ODBC driver could clearly access it. I did a little guessing, and I guessed that the problem was that LS:DO only supports ODBC 2.0 while Unicode calls in ODBC weren't available until ODBC 3.5.

We tried using LEI/LCLSX code -- same Notes client, same ODBC driver, same DSN -- and we got the data. So there you go. Good reason to use LEI, at least sometimes.

technorati tag: ,

ReplicaIDs Considered Harmful? (Thursday, Feb 15)
[ permalink ] [ e-mail me ] [ ]

There's an interesting discussion brewing in the comments of my last blog entry. We started off with the problem that the Notes URL:

notes://servername/databaseReplicaID?OpenDatabase

will actually check the Domain Catalog first, before it checks the server that is explicitly named in the URL (this is not considered a bug -- Notes is functioning as designed). Michael Urspringer confirmed this behavior, as well as the fact that changing the Notes URL to:

notes://servername/databaseFileName.nsf?OpenDatabase

will work "as expected" and check the server that you specify.

Oh, and SPR EAVM4THH42 indicates that doclinks work the same way (they always look at the Catalog before the server hint), because they too use database replica IDs.

So the discussion that's brewing is that Nathan Freeman asked why you would ever use a replica ID in a Notes URL anyway? Andy Broyles mentioned that it's handy in the case of mail file relocation, and I can buy that one. But in most cases I'm thinking that the file name is the way to go. Replica IDs are too smart for their own good. They try to second-guess you by saying "I know you said that this is the server you wanted, but I think this other one is better because it comes [alphabetically] first in the Catalog."

Personally, I don't normally like software to do too much thinking for me. When I say that I want to go to this server, I want to go to this server.

Where I get a little wishy-washy is in the case of doclinks. I can kinda see how the Catalog idea could work better with a doclink in a large international organization as long as each geographic region has its own Catalog (which I don't even know is possible -- I'm not an Admin). That way if someone in Australia sends a doclink to someone in Canada, if there's a local Canadian server that can serve up the document (and the Catalog is configured properly) then that's what is used.

However, this whole alphabetical lookup of a server in the Catalog is still a little unusual. I guess when you're naming your servers, you're always going to have to make sure to name the one with the best connectivity "Aardvark" or "AAAAcme" or something, to make sure it floats to the top of the list.

Notes:// URLs, Server Hints, and Domain Catalogs (Tuesday, Feb 13)
[ permalink ] [ e-mail me ] [ ]

A friend of mine is having a problem where he has a Notes URL like this:

notes://servername/databaseReplicaID?OpenDatabase

He has no icons for this database on his workspace, and yet when he clicks the link it opens a replica of the database on some other server -- not the one specified in the link.

So I did some searching and found this technote that indicates that calling @Command([FileOpenDBRepID]) to open a database uses the following logic:

  1. Look for an icon of the database on the workspace, and use that if it's available (if there are multiple icons, use the one at the top of the stack)
  2. Look for the database using the Catalog/Domain search, and use that if it's available
  3. Look for the database using the server specified in the server hint, and use that if it's available
  4. Look for the database on the user's Home Server, and use that if it's available
  5. Look for the database on the user's local machine, and use that if it's available
  6. Give the user the "Choose Servers to Search" dialog (listing the servers in your Home Server's Notes Network, and highlighting all servers for which you already have an icon on your workspace)

Okay, that seems reasonable... all except that second and third part. Those look reversed. According to the technote, even if you specify a server hint, the client will always check the Catalog first. And the Catalog is (of course) in alphabetical order, so if you happen to have a server in Anguilla then that one will have preference over a server that may be much closer to you.

Taking this a step further, this LDD post indicates that this is the same logic used when you open a database using a notes:// URL. So even though my friend was clicking this:

notes://servername/databaseReplicaID?OpenDatabase

he was getting the database on "anotherserver" instead of "servername", because "anotherserver" came first in the catalog.

At least, that seems like what was going on. Here are my questions, if anyone can help:

If the client always checks the Catalog first anyway, then the server hint doesn't do a whole heck of a lot of good, does it?

UPDATE: oh, and I realize that if the server name that is specified in the link is not available via DNS, then the server hint doesn't work. In case you were thinking that was the problem.

SOLUTION: Michael Urspringer did some testing and confirmed that (A) the Catalog server was indeed the problem in this case, and (B) using the database filename instead of the replica ID will fix the problem. Kurt Higley also said that the filename versus replica ID has always worked for him, so a big thanks to Michael and Kurt for coming back with the answer so quickly!

Thanks also to the anonymous commenter who said that SPR EAVM4THH42 indicates that doclinks work the same way (always look at the Catalog server before the server hint).