|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000888||NetSurf||[All Projects] General||public||2006-02-08 17:05||2006-02-10 08:12|
|Reporter||Sourceforge Import placeholder|
|Assigned To||Sourceforge Import placeholder|
|Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0000888: NetSurf fails to find fonts in EasyFontPro|
|Description||NetSurf (recent builds, including 08 Feb 2006 0045)|
fails to find fonts stored by EasyFontPro and so does
not offer them in its menu.
Deleting rufl_cache and trying again results in NetSurf
silently dying (example log from such an event attached).
EasyFontPro adds its fonts to Font$Path by the macro
<EasyFSPro$Fonts> which points to
There is no such Fabis0004 directory present and the
resulting <EasyFSPro$Dir>. contains a 0 subdirectory
followed by various numbered subdirectories. Presumably
normally EasyFontPro does some 'magic' when the
FontManager normally investigates the path.
Additionally, EasyFontPro turns all the files within
the original font directories into numbered files
within numbered subdirectories (presumably to more
efficiently store them) along with some internal record
of what is what.
I wonder if either or both of these factors are
tripping up the 'check for Outlines data' changes to
RUfl since a) the path doesn't really exist b) the
structure inside is not that of normal fonts.
EasyFontPro may fool the Font Manager but cannot fool
the Filer, perhaps?
|Additional Information||Imported from sourceforge bug http://sourceforge.net/support/tracker.php?aid=1427715 on Tue Dec 10 17:34:12 2013|
|Tags||No tags attached.|
|Fixed in CI build #|
|Reported in CI build #|
|URL of problem page|
|2013-12-10 17:41||Vincent Sanders||New Issue|
|2013-12-10 17:41||Vincent Sanders||Assigned To||=> Sourceforge Import placeholder|