View Issue Details

IDProjectCategoryView StatusLast Update
0000559luatexluatex bugpublic2015-03-21 15:00
Reporterpatrick Assigned ToHans Hagen  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformApple/Intel/64bitOSOS XOS Version10.6
Product Version0.65.0 
Summary0000559: Defining the same font twice messes up font expansion
DescriptionSee the attached files. It defines (sample.lua) a font twice:


local ok,f = define_font("texgyreheros-regular.otf",65782 * 12)
local num = font.define(f)

local ok,f = define_font("texgyreheros-regular.otf",65782 * 12)
local num = font.define(f)

When I use the second font, font expansion gets messed up. When I use the first font, everything looks fine. I have used some extreme settings to visualize the problem. And also, the hyphenation is in the wrong language, but thats just for the sake of simplicity.
Steps To ReproduceUnzip the attached zip file and run `luatex sample.tex`. You need texgyreheros-roman.otf somehwere in your TeX installation. The output looks strange. If you remove the first `font.define(f)` line in the sample.lua file (or change the font size or name to some other value) the output looks correct.
TagsNo tags attached.

Activities

patrick

2011-01-13 14:25

reporter  

bugreport.zip (1,383 bytes)

patrick

2011-01-13 14:26

reporter  

sample.pdf (12,930 bytes)

patrick

2011-01-13 14:27

reporter  

sample-ok.pdf (12,911 bytes)

Hans Hagen

2013-12-23 11:10

manager   ~0001203

font expansion is partly redone, so this needs to be tested in 0.78+

Taco

2014-01-03 13:43

administrator   ~0001208

Last edited: 2014-01-03 13:43

It appears that the bug is gone now, but I am surprised that other choices for the paragraph line breaks have been made. Is that a side-effect of ex-glyph?

(It could also be a different font version)

Taco

2014-01-03 13:44

administrator  

sample-taco.pdf (13,646 bytes)

Hans Hagen

2014-01-04 12:53

manager   ~0001212

in the latest lua/font there has been some kern fixes for disc nodes, so that could be a reason (as standard hz also messes with kerns which is debatable)

the current mechanism avoids several (redundant) calculations from the old code as well no longer uses cloned fonts, so maybe there could be less rounding loss

Hans Hagen

2014-01-06 11:23

manager   ~0001214

if there is a (new) issue it can become another tracker item

Issue History

Date Modified Username Field Change
2011-01-13 14:25 patrick New Issue
2011-01-13 14:25 patrick File Added: bugreport.zip
2011-01-13 14:26 patrick File Added: sample.pdf
2011-01-13 14:27 patrick File Added: sample-ok.pdf
2011-02-10 10:29 Taco Status new => assigned
2011-02-10 10:29 Taco Assigned To => Taco
2013-12-23 11:10 Hans Hagen Note Added: 0001203
2014-01-03 13:43 Taco Note Added: 0001208
2014-01-03 13:43 Taco Assigned To Taco => Hans Hagen
2014-01-03 13:43 Taco Status assigned => feedback
2014-01-03 13:43 Taco Note Edited: 0001208
2014-01-03 13:44 Taco File Added: sample-taco.pdf
2014-01-04 12:53 Hans Hagen Note Added: 0001212
2014-01-06 11:23 Hans Hagen Note Added: 0001214
2014-01-06 11:23 Hans Hagen Status feedback => closed
2014-01-06 11:23 Hans Hagen Resolution open => fixed
2014-01-06 11:26 Taco Status closed => resolved
2015-03-21 15:00 Hans Hagen Status resolved => closed