Menu
▾
▴
[pcal-interest] PATCH: New EPS Image Capability For 'pcal'
|
From: Marr <ma...@fl...> - 2004-11-02 02:48:45
|
Greetings Neeme, Stefan, and fellow 'pcal' users,
Quick Summary:
I've modified 'pcal' to allow printing of Encapsulated PostScript (EPS) images
in the box for a given day on a monthly calendar.
----------------------------------------
Background:
I'm a long-time Linux user. Back in Nov 2002, I decided to finally find a
good Linux-based calendar program to replace Broderbund's 'Calendar Creator'
for Windows, which was one of the last programs for which I still used
Windows.
I found 'pcal' and loved its printed output and its excellent configurability.
Unfortunately, it didn't support adding images to the various events, which
is something I always do for printed monthly calendars. For example, I like
to display a photo of each family member on their birthday along with the
usual text notation. I also like to display icons for various events
(Christmas, etc).
In Feb 2004, I finally added a capability to use (slightly modified, as
described below) EPS images (photos or icons or whatever) with 'pcal' and it
worked out much easier and better than I expected. I've been using my hacked
version to print monthly calendars since then and figured I should probably
formalize it a bit and submit it as a patch for consideration as part of the
next version of 'pcal'.
----------------------------------------
Documentation:
To use the new EPS image capability on monthly calendars, add a line like the
following to your 'pcal' configuration file:
May 10 image:/path/to/your/images/eric.eps 0.42 0.42 0 -8
The first part of the line is the usual specification of the date of the
event, as normally used by 'pcal'. Any valid 'pcal' syntax can be used
there. The 'image:' is a new keyword (provided by my patch) that specifies
the filename of the EPS image (optionally including the path). The last 4
numbers determine how the EPS image is displayed. They are the X-scale,
Y-scale, X-offset, and Y-offset values. Changing the X- and Y-scale values
resize the EPS image from its native size (1.0 = native size; you can go
higher or lower). The X- and Y-offsets adjust the image position (in
typographic 'points', i.e. in 72nds of an inch) within the box for that day
on a monthly calendar. With offsets of 0 for X and Y, the image will be
printed at the extreme left edge of the box for that day, just under the
numerics for that day. Positive X offsets move the image to the right and
positive Y offsets move the image up.
Obviously, depending on the size of the original EPS image and various other
issues, you may have to 'tweak' those last 4 values to get an image sized and
positioned exactly the way you like. Furthermore, depending upon what other
events are printed on that same day, you may need to change those values from
one year to the next, as other events which don't always fall on a fixed day
of the month collide with your image-attached event in successive years. My
configuration method is rather simplistic (some might even say 'crude'), but
it works and allows you to enhance your monthly calendars quite nicely.
Although someone might suggest that the image sizing and positioning might
best be automated more, I prefer to have full control over image sizing and
positioning. In the past, I've had problems with the positioning of events
and/or images in Windows' applications like Broderbund's 'Calendar Creator'
which sometimes try to be "too smart for their own good".
Note that you can still use your normal configuration file entries to display
text on the same event. For example, to display the text about a birthday
for someone born on May 10, 1991 ("Eric's 14th Birthday", in 2005), with the
image in the same box, use these 2 lines:
May 10 Eric's %-1991Y%oY Birthday
May 10 image:/path/eric.eps 0.42 0.42 0 -8
The Y-offset value of '-8' shifts the image down enough for the text above it
to be visible, given the font I'm using.
For another example, my "recycling collection" day falls on the second
Saturday of every month so I use these lines in my configuration file to
display the text 'RECYCLE!' with a little green 'recycle' logo:
second Sat in all RECYCLE!
second Sat in all image:/path/recycle.eps 0.029 0.029 50 -28
As long as you can fit them all by scaling and/or positioning, there is no
limit to the number of EPS images you can place in the box for a single day
of a monthly calendar. Just add successive lines for each image. For
example, on the "President's Day" holiday, I display little icons of George
Washington and Abraham Lincoln like this:
3rd Monday in Feb* Presidents' Day
#
# Normal Size:
#
### 3rd Monday in Feb* image:/path/washington.eps 0.080 0.080 8 0
### 3rd Monday in Feb* image:/path/lincoln.eps 0.22 0.22 48 0
#
# Collision-with-birthday(s) Size:
#
3rd Monday in Feb* image:/path/washington.eps 0.040 0.040 0 -28
3rd Monday in Feb* image:/path/lincoln.eps 0.11 0.11 22 -28
Note that I have 2 versions, one (commented out) that prints the icons at the
normal (larger) size for years when no other events collide on that day, and
one that prints the icons at a smaller size and a different position for
years when some other event (like a birthday) collides on that day.
Of course, you'll have to supply the EPS images yourself, but most calendar
programs for Windows probably already have a batch of ready-made icons for
your convenience. You might have to convert them to Encapsulated PostScript
(EPS), but that's a small price to pay for image-enhanced calendars,
right? :^)
Under Linux, I've used 'The Gimp' to convert photos to EPS and
'libwmf'/'wmf2eps' to convert various WMF icons to EPS.
Important!!! Note that you usually have to modify the EPS output in one or
more ways before the EPS image files can be used for 'pcal'. Firstly, you
must remove the 'showpage' command (e.g. by commenting it out with a leading
'%' character) at the end of the EPS file. As of version 1.2.5 of 'gimp', it
seems to put 2 PostScript 'translate' commands in the EPS output files.
Based on my experiences, you'll want to comment out both of those 'translate'
commands. For example, convert this:
% Translate for offset
14.173228 14.173228 translate
% Translate to begin of first scanline
0.000000 115.560000 translate
84.960000 -115.560000 scale
into this:
% Translate for offset
%%% DISABLED: 14.173228 14.173228 translate
% Translate to begin of first scanline
%%% DISABLED: 0.000000 115.560000 translate
84.960000 -115.560000 scale
Other conversion applications may require other 'gyrations' to make the EPS
output compatible with 'pcal', but you can usually figure out what's needed
by playing around with the EPS file. In general, I've found success by
commenting out all 'translate' commands (and the 2 parameters which precede
them, of course) and commenting out any 'showpage' commands. Your experience
may be different....
Since the creation of the proper EPS files and the positioning and the sizing
of those images often requires some trial-and-error tweaking, it's highly
recommended that you preview the PostScript output of 'pcal' before printing!
----------------------------------------
Final Notes:
Attached please find a single patch file which patches the 2 files needed to
make 'pcal' support the new 'image:' capability.
This patch should apply cleanly to the latest 4.7.1 distribution.
If this patch winds up getting applied to the next version of 'pcal' and
better documentation of my change is needed in the 'ReadMe' (or whatever)
file, please let me know and I'll be happy to supply more information.
Disclaimer: I've only compiled this under GNU/Linux (Slackware 9.1, using the
GCC compiler). I don't know if it will work on other platforms. I did use
the 'strncasecmp()' function (for case-insensitive, length-limited string
comparison) in two spots -- that may not be portable to other platforms that
'pcal' supports. One could easily replace them with the case-sensitive
equivalent ('strncmp()') if needed.
I've also posted this patch and some of the most important parts of this
email's content on the main 'pcal' site at Source Forge.
If anyone has any problems, questions, suggestions, or even criticisms, feel
free to email me.
I hope this enhancement proves useful to others!
Bill Marr
|