1. You want to print 10 lines on 1 5/8"
labels.. (see question #1 )
Lets make sure you have set Form Length and Label Height correctly.
Form Length controls page feeds. It corresponds to the distance from
the top of one lable to the top of the next label. For your label this
value could be two inches - which means a setting of 2000 in UMDPrint.
Label Height must correspond to the length of the printable label,
itself.
In your case, 1 5/8" means a setting of 1625 in UMDPrint.
The Shift Printing Down setting in UMDPrint could have an effect, but
most
people will have this value set to 0, so it is not likely to be an issue.
The Real Issue
Font selection controls the amount of vertical space required per line
of text.
Even at the same nominal point size, fonts vary in their vertical space
requirement.
Palatino is a large font on my computer. It takes more vertical space
per line, meaning that I can print fewer lines of text on a label.
Times New Roman is almost as tall as Palatino.
CourierNew, CourierPS, and Garamond are shorter. I think Garamond looks
better on spine labels (it is a serif font).
The Answer
If you want to print 10 lines of text on your 1 5/8" label, please
try:
Garamond, 10 pt., bold
2. You are unable to edit the "editable
screen label". (see question #2)
This happens if the editable screen label is too short to accomodate
the number of lines of text that already exist.
The Answer:
Fixed -Please upgrade to version 2.2
The Old Answer
Click on the "label profile" tab.
Adjust the screen size of the editable label, providing more height.
I recommend you set the height to its maximum setting: 200
Then click the button to "save the label group configuration".
This must be repeated for any label group which is affected by the "unable
to edit" problem.
Note: This will not affect how many lines fit on the real label when
you print.
3. UMDPrint can't control form feed
length on an Epson LQ-590 printer. (see question
#3)
This happens because the Epson printer driver for the LQ-590 is programmed
to work only with certain form (paper) sizes. It is unusually strict
in this regard.
The same thing is true of the Epson Stylus Color 1520.
Answer A - If you want UMDPrint to control the formfeed length :
This is an arbitrary limit set within the printer software. Solve the
problem by using a different (compatible) driver for the printer.
For the LQ-590, use the Epson LQ-570 printer driver that came with
Windows.
For the Stylus Color 1520, don't use the LQ 1550 driver (which I previously
suggested.) It introduces an issue with the left margin. You may want to try one of the following: Epson LQ-870, LQ-570,
LQ-500, LQ-850, LQ-1170.
Printing may slow down a bit, but it will work. And UMDPrint will be
able to control the form length for your printer.
4. UMDPrint version
2 always prints label information in the same sequence. You cannot print
tab-label information below the call number. (see
question #4)
First, to avoid a lot of frustration, you should know that UMDPrint
ignores the xsl form file. So there is nothing you can do in the xsl
file to control your label layout in UMDPrint.
Version 2 of UMDPrint assumes that all users want the fields placed
on their labels in this order (referring to the data fields in the xml
label data file Aleph produces):
a. Anything in the <tab-label-xx> fields.
b. Anything found in the <call-no-piece-xx> fields.
c. Anything found in the <call-no-piece-2-xx> fields.
d. Anything found in the <item-desc-piece-xx> fields.
e. Appended chronology taken from within a set of parentheses in the
z-30 description field. (If this option is turned on. Most sites don't
use it.)
f. Appended item copy info, taken from within the z30-copy-id field.
(If this option is turned on. I think copy # is more often present in
the item-desc-piece fields.)
Given this behavior, I don't know of any way, using UMDPrint,
to place info from a <tab-label-xx> field below the call number.
When UMDPrint 3 finally comes out, this will be addressed.
5. You want to print labels from the Serials "Arrive" screen.
Spine label printing, using UMDPrint, has been set up and works from the Item List, but not from the Arrive screen. (see question #5)
At the U of MN we made this work in two steps. The first step may not be needed.
It is included here because we haven't done any testing without it. So it could be needed.
First Step: On our Aleph server, we added a line for serial-item-label in the "form_print_method" table. The five entries in that table now read as
follows (although I am not showing the correct spacing here):
item-copy-label 20 EXECUTE LABEL_PRINT
item-copy-label 00 EXECUTE LABEL_PRINT
item-issue-label 20 EXECUTE LABEL_PRINT
item-issue-label 00 EXECUTE LABEL_PRINT
serial-item-label EXECUTE LABEL_PRINT
Second Step: On our Aleph server, we edited the file "../XXX50/tab/tab100"
We changed the line:
SERIAL-ITEM-LABEL=N
to read:
SERIAL-ITEM-LABEL=Y
This flag was added as part of an Aleph update sent out a year or two ago. For more details, you can see the explanation in the Aleph problem/support database.
Search for Problem Report 000011898
Just pretend that the text says "UMDPrint" instead of "LABEL500".
6. For info on Thermal Printers and UMDPrint, see our Thermal Printers Page.
Note: The problem described in question #7 might be specific to the U of MN Duluth site.Other sites have reported that they have users running Aleph as a non-administrator and have not seen this problem. kh 7.20.2007
7. Trying to print labels for various items using UMDPrint - and you just keep getting more copies of the very first label you printed. (See question 7) You may be running the Aleph client cataloging module as a restricted user under Windows.
We have a working solution - but the mechanism causing the problem is still a bit of a mystery. Read on..
Problems:
We instituted new security settings in Windows XP, and created "power user" accounts for our staff (instead of admin accounts). Immediately, our cataloging staff experienced these problems..
Screen parameters for item searches were no longer saved from one Aleph client session to the next.
We could only print labels for one specific item. It didn't matter what item we were trying to print a label for.. We always got the same darned label.
Temp files containing label data - separate files for each item we wanted a label for - were being accumulated in the directory c:\temp\Aleph\.
Observations and theories:
When you click the "label" button for an item, it is normal for the aleph client to place temp files (with label data) in c:\temp\Aleph\. I don't think it is normal for those temp files to stay there and accumulate.
The command line used by the Aleph client to call UMDPrint.exe always contained a reference to the same old temp file - even though a newer temp file had been created with data for the label we wanted to print.
The c:\temp\Aleph directory was read-only. And the user could NOT turn off the read-only attribute. This implied that the Aleph client - run under our users' Windows accounts - might have difficulty deleting or updating certain files on the local hard drive. If this could affect label printing, it could also affect the retention of screen data (options selected in the item search screens).
Logging into Windows as a user with administrator rights resolved these problems.
This tends to agree with our ideas.
Solution:
Our staff still log into Windows as "power users", with all security settings intact. But we set up a method for running the cataloging module with elevated priveleges.
Item search parameters are retained, just like the used to be, for our users.
Labels print correctly.
Temp (label data) files no longer accumulate in c:\temp\Aleph\
