<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Additional information (don't know why I didn't spot it before):<br>
<br>
I had set the expansion step to 30, the same value as shrink and
stretch, pretty stupidly. Anyway, if I put it to something lower, I
apparently have to increase the glyphs' expansion_factor for the
problem to show up. For instance, with step = 10, expansion_factor
should be at least 1214.<br>
<br>
(Also, my LuaTeX is v0.66 rev 4136. And I had left a useless
inspection of post_linebreak_filter in the file I've sent, sorry for
that.)<br>
<br>
Best,<br>
Paul<br>
<br>
Le 20/04/2011 15:14, Paul Isambert a écrit :
<blockquote cite="mid:4DAEDC2E.9040603@free.fr" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Hello there,<br>
<br>
I think I've found a bug, but since I'm still a bit uncomfortable
with fonts and I can't reproduce the problem with luaotfload
(haven't tried very hard, though), I think it wise to ask
knowledgeable people before polluting the bug tracker.<br>
<br>
The problem is entirely contained in the attached files.<br>
<br>
The Lua code is an extremely blunt font loader, as minimal as
possible while still displaying the problem; it is also extremely
stupid: on first use, it sets the glyph to their Unicode slots;
the second time, it puts small caps in the slot of the lowercase
letters (it is meant to spot Minion's small caps). In other words,
after:<br>
<br>
\font\fontone=MinionPro-Regular.otf at 10pt<br>
\font\fonttwo=MinionPro-Regular.otf at 10pt<br>
<br>
\fontone writes normally, while \fonttwo writes in small caps.
That's the way I use a font with small caps (I suppose that's the
only way, unless you change glyphs in callbacks). I've used Minion
because it is distributed freely with Adobe Reader.<br>
<br>
Now, if you look at the PDF or compile the source, you can see
that it's all wrong; sizes are at random and the paragraph is like
raggedright. If \fonttwo isn't loaded, everything is fine;
otherwise, disaster, even though \fonttwo is loaded <i>after</i>
the paragraph has been built, which seems to indicate something
has gone wrong when outputting to PDF (of course the problem also
shows up when \fonttwo is loaded before the paragraph). Judging
from what I can read in the uncompressed PDF file when comparing
to an unproblematic file, spaces between characters are all wrong
(I don't know where those spaces come from, by the way; there are
no font kerns with this fontloader).<br>
<br>
A few remarks about the behavior:<br>
<br>
- It depends on font expansion; without \pdfadjustspacing,
everything is fine.<br>
- It also depends on the value given to the glyphs'
"expansion_factor" field; if 484 or higher, it goes wrong; if 483
or lower, everything is fine. The value of that threshold depends
on the font (e.g. it is 909 for Chaparral).<br>
- If there is a one-line paragraph before the first paragraph,
everything is fine.<br>
- If there is a page break before the second font is loaded, again
everything is fine.<br>
- The fonts should be loaded at the same size; if e.g. \fonttwo is
10.1pt, the problem vanishes.<br>
<br>
Did I do anything wrong or is that a patented bug? (Actually, I
think that even if I did anything wrong the behavior is so strange
that it's very probably a bug anyway.)<br>
<br>
Best,<br>
Paul<br>
</blockquote>
</body>
</html>