| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
| |
This info is indeed valuable on top of the commit hash, thanks to @jfbu
who complained about its absence.
|
| |
|
|
|
|
|
| |
With commit 8c0dd0ebbedd kern accesses were fixed but the results never
tested for the lookup, which caused the default which is set up before
to be nil’ed. Fix this by reusing the value we initialized the kern
factor to.
|
| |
|
|
|
|
|
|
|
|
|
| |
With the new loader, the ``units_per_em`` field resides under the
toplevel TFM structure with the key ``units``. For AFM fonts, it is not
fount under the metadata table too, which we are currently querying.
Thus we prefer the main value, falling back on metadata only in case it
is missing.
At this occasion, tidy up our unit lookup helper and use that wherever
we need access to the values ourselves.
|
| |
|
|
|
|
|
| |
Defining a combination did not override the default file: lookup so
every font defined that way will at font embedding time trigger a reload
of the index on account of a missing file. Setting the ``combo:`` lookup
will prevent the issue.
|
| |
|
|
|
|
|
| |
Due to the origin in other parts of Luatex, some messages in this file
were logged under the “load” facility; corrected. Also, the combo
mechanism still spits debug levels of noise at log level zero; raised to
two.
|
| |
|
|
|
|
|
|
| |
Adress issue #350
For some reason our stack copy of the current node gets double-freed.
Since the “components” field will probably vanish soon, we can get by
for now by skipping the explicit free.
|
| |
|
|
| |
This could become the common check eventually.
|
| |
|
|
|
|
|
|
|
|
| |
The version check was removed by accident in commit 5ce60cc98a30. This
isn’t normally a problem except when people start to run the Pretest
version on ancient Luatex binaries … In any case, the check must be
present. While we’re at it, make the error messages consistent between
the tool and a live TeX run. This can’t cover the fact that there is no
(direct) means of determining the Luatex version when not running in TeX
mode, so the checks still aren’t equivalent.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix issue #351
The letterspace node handler dereferences kern values of non-existant
character information under some circumstances, causing Luatex to crash.
To avoid this crash, check more thoroughly for the presence of the
fields accessed.
Discovered by @schlcht
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows to domesticate packages that quite disrespectfully only use
“anon:” lookups. Example from the test repo:
\documentclass{scrartcl}
\usepackage{fontspec}
\directlua{
config.luaotfload = config.actions.apply
(config.luaotfload, { run = { anon_sequence = { "my" } } })
}
\directlua{
luatexbase.add_to_callback(
"luaotfload.resolve_font",
function (spec) spec.name = "comic.ttf" end,
"user.openbsd_style")
}
\setmainfont{Adobe Premier Deluxe Overpriced}
\begin{document}
There is no escape.
\end{document}
|
| | |
|
| |
|
|
|
|
|
|
| |
The arguments to “--find” on the command line avoided calling the real
index API functions and used crude approximations instead. In order to
make “--find” obey the new “anon-sequence” configuration item, it needs
to access the normal resolvers instead. This requires certain
adaptations to allow for a fallback on the “file:” lookup.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Implements #263
The resolvers have already been decoupled a while ago but the goal of
allowing the sequence to be reordered at will was still outstanding.
Add a config option “anon-sequence” that is parsed as a comma-delimited
list of sequence components.
|
| |
|
|
|
|
|
|
| |
Fix issue #344
An incomplete matching rule for determining configuration values caused
return bytes (0x0d) to leak into the configuration if Windows style
newlines are used. Fixed by adapting the pattern.
|
| |
|
|
|
|
| |
@dohyunkim pointed out that due to the too broad criteria, secondary
style variants like “heavy”, “black” ended up getting picked over the
actual “bold”.
|
| | |
|
| |
|
|
|
|
|
| |
When adapting to the new loader we repeated the mistake of classifying
“bold” faces by too broad criteria, thereby sabotaging the recognition
of large families from Adobe. Restore the old behavior by only treating
those faces as bold fallback that advertise and exact weight of 700.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Fix #342
Due to the reassigned fontname fields, certain values designating styles
ended up being interpreted wrongly and members of the font families
ended up in the wrong table.
Thanks to @dohyunkim for spotting the issue.
|
| |
|
|
|
| |
Forward the errors received from require() in a readable manner and exit
on the spot.
|
| |
|
|
|
|
|
|
| |
Fix #341
Hironori Kitagawa pointed out that the patch for the other math
parameters doesn’t work. Turns out Hans relocated the “mathconstants”
table …
|
| | |
|
| |
|
|
|
| |
Provide fallbacks in case no ‘X’ character is available for capheight
measurement.
|
| |
|
|
|
|
|
|
| |
Addresses #341
This cleans up the font patching code we inherited from Fontspec. In
addition to treating the bitrot with an extra dose of fungicide, we also
make the process in which the final values are chosen more transparent.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Fix #337
This amends the apparent failure of luaotfload-tool as reported by @eg9
and others.
|
| |
|
|
|
|
|
|
|
|
| |
The current PFB loader, although it is indeed completely independent of
the FF libraries, is not yet feature complete. Only the loading of
vectors is supported which suffices for font rendering given the AFM
information.
According to Hans, we have decent chance of it growing into a
full-fledged reader for 1.0.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix #338
Due to the new loader, certain tables were relocated inside the fontdata
structure. This would cause a crash with certain kinds of fonts, most
notably those for which TeX metrics exist.
Many thanks to @aminophen and @u-fischer for their help in tracking this
down.
|
| |
|
|
| |
Reported by @u-fisher on Github.
|
| |
|
|
|
|
|
|
| |
This reverts commit c4c250414a83cc8c4ae99d286ed69a3763510609.
Partially, anyways: All mentions of the PFA format were stripped.
Since the new loader adds back in support for PFB-flavored PS fonts
without AFM we should support it from Luaotfload as well.
|
| |
|
|
|
| |
Hans fixed a couple issues due to our reports. Also, brand new Lua based
PFB loader.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Thanks to @dohyunkim for reminding me to be thorough!
At least in our own files. A patch has been sent upstream to apply the
same change to the generic loader.
|
| |
|
|
| |
It’s sort of official now ;)
|
| |
|
|
|
| |
The “AFM” code stays since PFB accompanied by an AFM file is still
supported by the fontloader.
|
| | |
|
| |
|
|
|
| |
Unsupported as of now. They were only ever supported by accident and
very incompletely, which was misleading.
|
| |
|
|
|
|
|
|
| |
The Lua fontloader doesn’t support these formats and they’re very low
priority. There is no “shortcut” like with the FF loader anymore which
would parse such files into the same data structures as {O,T}TF. Support
for postscript formats may come back at some point in the future if
there is demand.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Another take on https://github.com/lualatex/luaotfload/issues/334
The parsing issues we aim to prevent occur with spaces because Luatex
treats them as argument separators. Hence apply quoting only if
necessary. Also use the appropriate format string as a defense against
garbage inputs.
|
