Sophie

Sophie

distrib > Mandriva > 8.2 > i586 > by-pkgid > efc75c1dcfa45d4b2a545c38cda30759 > files > 142

pfaedit-020312-2mdk.i586.rpm

<HTML>
<HEAD>
  <!-- Created with AOLpress/2.0 -->
  <!-- AP: Created on: 28-Jun-2001 -->
  <!-- AP: Last modified: 16-Dec-2001 -->
  <TITLE>Finding common font problems automagically</TITLE>
</HEAD>
<BODY>
<H1 ALIGN=Center>
  Finding common font problems automagically
</H1>
<P>
<IMG SRC="findprobs.png" WIDTH="276" HEIGHT="502" ALIGN="Right">Nobody is
perfect.
<P>
Well, I'm not.
<P>
When you draw you characters you are likely to make some minor errors, like
having stems with slightly different widths in different characters, or having
lines which aren't quite vertical or...
<P>
PfaEdit's Find Problems command can help track down some common errors. It
won't fix things for you (who knows, some of the so-called "problems" might
actually be what you wanted), but it will point things out to you that you
should look at.
<P>
This command works either in the font view or the outline view. In the font
view it will examine all selected characters for errors, and if it finds
any open a window looking at the character and post a (non-modal) dialog
saying what the error is. You may then correct the problem and press the
[Next] button in the dialog when you are done, or you may stop the command
with the [Stop] button. Behavior in the outline view is similar, except that
it only refers to that one character.
<P>
Normally after finding an error PfaEdit will post a dialog explaining what's
wrong (and sometimes what it expected to find and what it actually did find).
But if you find that time consuming, you can ask that PfaEdit simply open
the characters which might have problems and selecting those bits that should
be looked at. (I may take this out, it's how things used to work. Seems silly
now).
<P>
PfaEdit can detect the following potential problems:
<P>
<STRONG><BIG>Open Paths</BIG></STRONG>
<P>
All of your paths should be closed, that is they shouldn't have any end points
the way a line segment does, but should connect back to their beginning.
This is often caused by being a little careless with the last point on a
path, and instead of joining it to the first, you just put it near the first.
If PfaEdit detects any open paths it will select the entire path, and stop
to let you fix things up.
<P>
<STRONG><BIG>Points Too Close</BIG></STRONG>
<P>
Some of PfaEdit's own commands get confused by tiny splines, on the order
of one unit or less, and anyway if you have several points very close together
it is unlikely that they will make a detectable difference when the font
is printed. Probably you should remove one of them... If PfaEdit detects
two points on the same path which it deems to be too close it will select
both, stop and let you fix things.
<P>
<STRONG><BIG>X near [val]</BIG></STRONG>
<P>
Often there will be a set of features which should be consistant across the
entire file. For example the left side-bearing of the characters "BDEFHIKLMNPR"
should perhaps all be the same. This will let you enter in the desired
side-bearing value, and then PfaEdit will find all characters with points
that are near, but not exactly on the desired value. Where "near" is defined
at the bottom of the dialog (in this case, everything within 3 units -- in
either direction -- will be near). If it finds an errant point, PfaEdit will
select it, stop and let you fix it.
<P>
<STRONG><BIG>Y near [val]</BIG></STRONG>
<P>
This is the exact counter-part of the above command except for being in the
Y direction. Often times this check is more efficiently done by the following
check...
<P>
<STRONG><BIG>Y near standard heights</BIG></STRONG>
<P>
In Latin, Greek and Cyrillic alphabets there are certain standard heights
that PfaEdit expects to find: the baseline, the height of lower case letters,
the height of capital letters, the height of lower case letters with ascenders
(often the same as, or very close to, the capital height), and the depth
of lower case letters with descenders. For this command PfaEdit defines these
heights to be 0, the height of "x", the height of "I", the height of "l"
and the depth of "p" (If you are working on a Greek or Cyrillic font and
don't include the Latin alphabet, PfaEdit will pick similar letters from
your alphabet). Then PfaEdit will search for any points which are "near",
but not on, these heights. Again where "near" is defined at the bottom of
the dialog. If it finds such a point, PfaEdit will select it, stop and let
you fix things.
<P>
<STRONG><BIG>Edges near horizontal/vertical/italic</BIG></STRONG>
<P>
It is very easy to create a line which is almost, but not quite, vertical.
This will check for that situation. And for horizontal, and (if your font
has an italic angle) for lines which are almost but not quite parallel to
the italic angle. If it finds one of these, PfaEdit will select the two end
points, stop and let you fix things.
<P>
For horizontal lines it will tell you the y coordinates of the two end-points,
for vertical lines it will show you the x coordinates.
<P>
<STRONG><BIG>Control points near horizontal/vertical/italic</BIG></STRONG>
<P>
The above check only looks for straight lines, this one looks for curved
lines that begin or end near horizontal (vertical, italic angle).
<P>
<STRONG><BIG>Control points
odd</BIG></STRONG><IMG SRC="cpodd.png" WIDTH="210" HEIGHT="215" ALIGN="Right">
<P>
Consider the character at right, the selected point has a control point that
is far outside of what is reasonable and is probably not where it should
be. This will check for such points.
<P>
Technically it will search for all control points, which when projected onto
the line between the two end points lie outside of the segment between the
two.<BR Clear=all>
<P>
<BIG><STRONG>Hints controlling no points</STRONG></BIG>
<P>
This is a bit esoteric, and is present to provide a work-around for (what
I think is) a bug in ghostview. Consider the following character
<P>
<IMG SRC="phi-nohints-outline.png" WIDTH="89" HEIGHT="151">
<IMG SRC="phi-nohints-filled.png" WIDTH="93" HEIGHT="121">
<IMG SRC="phi-hints-outline.png" WIDTH="72" HEIGHT="133">
<IMG SRC="phi-hints-filled.png" WIDTH="93" HEIGHT="125"><BR>
The first two images show the character with no hints, first as seen in PfaEdit,
then as displayed by ghostview. The result looks good. If we add hints to
the two curved stems then ghostview gets very confused. I don't know enough
about hints to know whether there should be hints there. I am assuming so,
which is why PfaEdit will generate them. But this command will detect this
problem if in fact it is a problem. If PfaEdit finds this it will select
the offending hint and allow you to fix things (probably the best fix is
to add curved points at the extrema of all the curved splines, this is actually
recommended by adobe anyway
(<A HREF="http://partners.adobe.com/asn/developer/pdfs/tn/T1_Spec.pdf">T1_Spec.pdf
</A>section 4.1)).
<P>
<STRONG><BIG>Points near hint edges</BIG></STRONG>
<P>
If you have a character like "H" where the main vertical stems are broken
by the cross bar, it is all two easy to make the top part of the stem a slightly
different width than the bottom. Now the hinting process figures out all
the stems. So this command, in essence, is looking for points which are slightly
off from a stem. (again, near is defined at the bottom of the dlg). If PfaEdit
finds such a point it selects it, stops, and allows you to fix it up.
<P>
<BIG><STRONG>Hint width near [val]</STRONG></BIG>
<P>
Usually one wants many of the characters to have a consstant stem width,
and this command will check that all stems near the indicated value are that
value (again near is defined at the bottom of the page). If PfaEdit finds
a bad stem it will select it, stop and allow you to fix things.
<P>
<BIG><STRONG>Path Direction</STRONG></BIG>
<P>
Both PostScript and TrueType require that paths be traced in a clockwise
fashion. This usually doesn't matter, but ghostview will get confused by
hinted characters which are not clockwise. This command will detect whether
this constraint is violated. It does not correct the problem (as
<CODE>Element-&gt;Correct Direction</CODE> would).
<P>
Currently the command will report the same error several times if you do
not fix the problem. That's sort of a bug, but I don't see an easy way around
it yet. 
<H3>
  <STRONG>Flipped References</STRONG>
</H3>
<P>
As above PostScript and TrueType like clockwise paths. If you have a flipped
reference then either the reference or the original character will be drawn
with a counter-clockwise path. To fix it you should Edit-&gt;Unlink the reference
and Element-&gt;Correct Direction.
  <HR>
<P>
If your font is a CID keyed font you will also get:
<P>
<STRONG><BIG>Check for CIDs defined twice</BIG></STRONG>
<P>
Looks through the font set to see if there are any CIDs which have valid
glyphs in two or more fonts.
<P>
<STRONG><BIG>Check for undefined CIDs</BIG></STRONG>
<P>
Looks for CIDs which have no glyphs defined for them in any font. This is
a fairly common occurance in CID fonts, so use this with caution.
</BODY></HTML>