Hi,
I am working on an embedded project which requires CJK truetype fonts.
Since it is an embedded system, I want to save as much disk space as
possible.
The fonts we are using seem to compress to about 70% of their original
size - which could save around 13 MB on the ROM image.
I
It's interesting theme for CJK people, but difficult
to give quick answer.
The meaning of embedded system is too broad to guess
the system limitation, in comparison with desktop,
laptop, netbook or OLPC, please describe more :-)
# small ROM but large RAM?
# consuming CPU is better than
Ah, I slipped to mention about the font program size and
the expected resolution. Michiel, thank you for reminding
it.
In CJK Ideographs, apparently, the number of control points
to draw Bezier/Spline curve is greater than Latin script.
The number of the operator to connect the control points
is
Hi,
Have you tried wqy-microhei-fonts? It only consumes 5.3 M disk space, and
is used for Linux LiveCD.
URL: http://wenq.org/enindex.cgi?MicroHei%28en%29
Thanks,
Peng Wu
On Wed, Sep 8, 2010 at 12:30 AM, Matthew Tippett tippe...@gmail.com wrote:
Hi,
I am working on an embedded project
Also... there are a couple other patches included in this one, that can
/ would be disabled by default, like zipped fonts, etc.
Another feature that I've enabled in this version of the patch is one
that makes the emboldening function ignore the Y direction. In my
opinion, it looks
James Cloos cl...@jhcloos.com writes:
The C version does away-from-zero rounding.
MB Do you have test cases that show this? I tried using random inputs,
MB but even up to billions of iterations, I can't seem to find a set of
MB inputs where my function yields different results from yours.
Graham,
Here are the results of my performance testing. I was a bit surprised by the
results.
In gray_convert_glyph, the time is distributed as follows:
OLDNEW
render_line 20%15%
render_cubic 15%33%
render_scanline 14%10%
split_cubic6%
That is very interesting and very useful - in fact I think the more surprising
a
test is, the more useful it is. I'll have to look into your test case carefully
as well. I might not be able to do it for a day or to, though.
Where does your test data come from? Actual fonts, cooked up data, or
After trying various other fonts, I settled on using a single large (14,000
glyphs; 800,000 Bezier curves) CID-keyed Type 1 font, which seemed to show
pretty average behaviour.
I'm working on an implementation of something like Hain's algorithm now.
It'll be interesting to see how it
With 14,000 glyphs, I imagine that's a CJK font. I think there might be
different characteristics from a typical Latin font. I think we also ought to
try out a similar number of Latin glyphs, which could be done by rasterizing
all
the glyphs in a Latin font at varying sizes and rotations. In
I've now implemented something based on Hain's research and it seems to be
measurably faster than previous FT approaches. I have used Hain's paper (now
available from http://tinyurl.com/HainBez) to provide some sensible heuristics
rather than implement all his stuff in detail, and done so
Here are some test results with Latin fonts (40 thousand curves from fonts at
various point sizes).
Trace results:
CJK CJK CJK LATIN LATIN
OLD NEW HAINNEW HAIN
MB == Miles Bader mi...@gnu.org writes:
MB Hm, are you sure that's not backwards? When I tried the git C version[*],
MB as well as your most recent FT_MulFix_x86_64, it returned 0x8506...
Odd. Adding your algo to my test app, I get:
7AFA8000, , 8505, 8505, 8506
#
James Cloos cl...@jhcloos.com writes:
Since FT's C version uses longs, though, this:
int another (long a, long b) {
long r = (long)a * (long)b;
long s = r 31;
return (r + s + 0x8000) 16;
}
That's not correct though, is it? The variable s should be the all
sign portion of the
14 matches
Mail list logo
