?
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
>> The largest number of hints is 4111 (!).
WL> Ouch!
That glyph (uni2591) is an offset array of 16x16 circles.
Not hinting that one would certainly be fine.
(U+2591 is LIGHT SHADE.)
-JimC
--
James Cloos <cl...@jhcloos.com> OpenPGP: 0x9
AP == Alexei Podtelezhnikov apodt...@gmail.com writes:
AP Never mind. Right-shifting negative numbers is implementation defined
AP (ANSI or C11), so it is not portable.
Would replacing the 16 with / 65536L be fully portable?
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP
WL == Werner LEMBERG w...@gnu.org writes:
WL Fixed now in git. Please test, and thanks for the report!
Indeed, the scaling-ppem-wobble is gone.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
be a pain.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
, the new code adds 2 calls to add, but removes two calls to
srl and removes one call to stx, for a net reduction of one instruction.
It looks like the more correct code should not slow freetype enought to
notice, and for some architectures and fonts may improve performance.
-JimC
--
James Cloos cl
) and ghostsrcipt-9.07.
I run git master of freetype and everthing above other than ghostsrcipt.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
':
.../freetype2/src/base/ftcalc.c:208:31: error: 'FT_Int64' undeclared (first use
in this function)
d = (FT_Long)( c 0 ? ( (FT_Int64)a * b + ( c 1 ) ) / c
^
and so on.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
o == octoploid octopl...@yandex.com writes:
o Compiler is gcc-4.8.
I also used 4.8.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman
int==int32_t to avoid the
porting issues seen on ILP64.
Certainly all of amd64, arm64, sparc64, mips64, ppc64 are I32/LP64.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
2048f02e15d658517f23ad2493b7ee53b72c605a.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
How did you extract the font that it came out in an SFNT container?
I would not expect an SFNT given those /Font and /FontDescriptor objs.
Is the pdf itself available?
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
where it came might be instructive.
Or might just be a rabbit hole.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
WL == Werner LEMBERG w...@gnu.org writes:
WL Is it really `spotty'? I've never tested it, ...
Try (a modern version of) gnu emacs to give libotf a whirl.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel
and the moments of the enclosed space
nicely happened to be the same.)
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
, the conversions from % to are beneficial for simpler
compilers; they are also at least as easy to read and comprehend.
The same goes for the other simplifications in the patch.
[Following lkml (and now xorg) style here:]
Reviewed-by: James Cloos cl...@jhcloos.com
-JimC
--
James Cloos cl...@jhcloos.com
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
well.
Some fonts – Adobe’s more complete families are among the examples –
contain (opentype) features which enable proportional digits. In
opentype, those features would be in the GSUB table. ttx decodes
GSUB well enough that it should be easy to understand.
-JimC
--
James Cloos cl
If everything's fine, please post a complete patch again so that I
WL can apply it.
Will do.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman
FT_LONG64.
But that shouldn't be needed on LP64 archs.
Perhaps the #if FT_SIZEOF_LONG == 8 case should also #define
FT_CONFIG_OPTION_FORCE_INT64 ?
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
should be uncond-
itionally set when on a LP64 arch.
And gcc's output even on ILP32 arches is generally better than
freetype's !FT_LONG64 code, since most such archs have a 32x32=64 bit
integer multiply instruction and gcc is smart enough to notice that
the multiplicands are 32 bits.
-JimC
--
James
(essentially the paragraph you've
WL mailed to describe the 0x7FFF trick).
Will do. (It may take a day or two.)
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http
the trick that adding 0x7FFF when
the product is negative causes the same round-away-from-zero that
the current code does.
commit 94dc0c20554f3a3d709711f2c43ac65ab7c68afe
Author: James Cloos cl...@jhcloos.com
Date: Mon Apr 4 11:35:39 2011 -0400
Improve the version of FT_MulFix() which is used when
, but that looks like a good
match for the 30009 unique cidNs ttx says are in the cmap table.
Is there an example of a font with more than 42 subfonts?
I tested with ff 20100501, gentoo amd64 compile.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
АП == Алексей Подтележников apodt...@gmail.com writes:
АП ONE_PIXEL / 8 looks good! I hope everyone agrees that 244_8.png is not worse
АП than 243_16.png. See attachments.
It looks fine to me.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
a patch to fix the
comment to say that it is one 16th of a pixel might be better?
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo
that fits into a single register, then
that last bit of C might be optimal, yes?
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo
there.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
, though, I'd be happy to know!
Thanks for also looking at it.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
, 0
In that example, 8505 is what the C version generates.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
for mips64, too, where I expect it will be more important. I also expect
that the i386 version could be tidied a bit.
Is the amd64 version desired, given how little benefit it has?
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
heavily only for the common case where p0, p1, p2 and p3 have
GA r-coordinates (using Hain's notation) in that order, and
GA s-coordinates with the same sign.
Consequent to your second point, that is also true.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
points are on the same side of the
midpoint?
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
to.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
for testing; I'll need to output
renderings to png or netpbm when testing on remote boxen
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman
/edit
/match
/fontconfig
Not every app will honour the filter choice; most distributions'
versions of cairo will, some versions of xft may. I *think* current
versions of qt do, but I'm not certain of that.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
to be to prefer only-
ever-non-aa, but eventually performance would become more important
than appearance. But I would never want to mix them.)
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype
in the coming months; ghostscript trunk (which
is expected to be released in the next few weeks as gs 9.0) defaults to
freetype for type1, cff and sfnt fonts.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing
I tested master and master plus the proposed patch against a number of
cff fonts; in every case where I noticed missing glyphs with master,
they rendered properly after applying the patch.
I used a combination of xfd(1), ftview(1) and ftdiff(1) to do the testing.
-JimC
--
James Cloos cl
that it is intentionally fuzzy...
Ah, so you prefer aliased standards over anti-aliased, yes? :^) ☺
Seriously, though, I would not be surprised even one bit to find that
they intentionally left it fuzzy.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
wonder whether the Overshoot_Top and Overshoot_Bottom flags remain
constatnt when the glyph is flipped with FT_Set_Transform()?
If Vertical_Sweep_Drop() is the problem, chaning it to test more than
just =50% may have significant effects elsewhere.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP
was added in 2000, back in the 2.0
timeframe.
Certainly everything since 2.1.0 should work.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman
,
and that was between 2.1.8 and 2.1.9.
It is possible that the font is CID-encoded and that might explain why
you are having difficulties with it.
Other the freetype, you might want to see what the otfinfo(1) tool in
http://www.lcdf.org/type/lcdf-typetools-2.82.tar.gz has to say about it.
-JimC
--
James
on the stack.
Perhaps you were thinking „large1 large2 num div div“?
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype
/freetype2-demos.git/description
are the direct URLs to the files in question.
I can't tell from sv's docs how one could edit them; it may require a
support request
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype
.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Incidently, would it be easier to fix up the commit messages in the
(rsync of the) rcs files before runnign cvs2svn, than in the converted
git repo?
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing
option-file equivilent) will
be needed, and it'll take about 10 minutes on a high-end box.
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman
the instructions get run?
-JimC (thinking up corner cases)
(For the curious: it turned out to be 6 dm of snow in need of shoveling
the other day; but at least it was mostly nice, soft powder.)
--
James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6
buried in a snow drift. ;^)
-JimC
--
James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
axismap-design_points[axismap-num_points - 1];
+return FT_INT_TO_FIXED(axismap-design_points[axismap-num_points - 1]);
}
This time compile tested, not just Obviously Correct™.
-JimC
--
James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6
that:
(master-axis[i].def)16 == master-axis[i].minimum
So thre seems to be a missing or incorrect shift someplace and every
time it occurs the default value is the minimum value. (Assuming that
/DesignVector is what master-axis[i].def returns.)
-JimC
--
James Cloos [EMAIL PROTECTED
for the second issue, given that the initial
display is different from a redisplay.
Incidently, ftdiff.c,v is a+x in CVS:
,{ rsync cvs.sv.gnu.org::sources/freetype/ft2demos/src/ftdiff.c,v }
| -r-xr-xr-x 63623 2007/04/02 09:43:48 ftdiff.c,v
`
Otherwise: COOL CODE!!
-JimC
--
James
by changing the point size with UP or DOWN does not show up
after applying the above patch. There is probably still a bug in
ftdiff.c or in the library, but I don't see it and fixing the res
bug hides it.
-JimC
--
James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6
)
| #define FT_STRCPYN( dst, src, size ) \
| ft_mem_strcpyn( (char*)dst, (const char*)(src), (FT_ULong)(size) )
`
I suspect most users expect the same semantics as strncpy(3), in that
at most size octets are copied. It seems there needs to be a size--
in that while loop, yes?
-JimC
--
James Cloos
failing? Or
did something change in fontconfig? I'm too tired now to grep the
histories (Almost 24 hours up and counting)
Should FT_Get_Glyph_Name()'s last arg be sized to allow any legal
PostScript identifier (ie should it be 128)?
-JimC
--
James Cloos [EMAIL PROTECTED
the subroutinize flag, all characters are
Axel displayed correctly using FreeType 2.3.0, too.
I am currently at cvs HEAD as of 2007/01/08, so the bug was already
in as of then. I have to upgrade again tonight, but if you are seeing
it in the release I doubt that'll help
-JimC
--
James Cloos
in renderings where the
a or o overhang wider than the underbar, whereas the cff loader
renders them the same width as the underbar.
-JimC
--
James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
, but mingliu.ttf (again, not .ttc) from:
http://download.microsoft.com/download/OfficeXPStandard/ie_zht/1/W98NT42KMe/EN-US/ie_zht.exe
is one of the trick fonts. But a bit larger at 6+ Megs.
That URL even seems to still work
-JimC
--
James Cloos [EMAIL PROTECTED] OpenPGP: 0xED7DAEA6
the interpreter iff ft 2.1.9, but I can't see anything
that could do that
-JimC
--
James Cloos [EMAIL PROTECTED]
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
David == David Turner [EMAIL PROTECTED] writes:
David here's attached a small patch to libXfont-X11R7.0-1.0.0 that I've just
David written to let the library compile with 2.2
I'm giving it a test now. I should have a report back by the end of the day.
-JimC
--
James H. Cloos, Jr. [EMAIL
I compiled libXfont-1.1.0 with your patch and then xfs-1.0.2 (the
X Font Sever) against that. Both are also against freetype-2.2.1.
I did these via the gentoo ebuilds (hacking the libXfont ebuild to
add your patch), so I'll have to recompile to get better debugging,
but running the xfs under
My test of the freetype module showed that I could cause a crash by
loading any -iso10646-1 ttf font I tried; but using an eight bit
encoding never caused a crash. I didn't try any other sixteen bit
encodings (such as legacy CJK encodings) and I didn't try otf or
type1 fonts in that test.
FWIW.
Then I am out of ideas.
I'll have to give it anohter test on my box to see whether I still get
the crashes. I have to upgrade from 99.14 to 99.15 anyway
-JimC
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Hin-Tak == Hin-Tak Leung [EMAIL PROTECTED] writes:
You also need the freetype module loaded in X.
Hin-Tak yes, I Know that - how else can I view web pages with
Hin-Tak truetype fonts?!
Mozilla uses client-side fonts via libXft. The crash in question is
in the X server's freetype module which
If none of those fonts generates a crash, I have to presume that
either the X server is not using freetype 2.1.0 for its freetype
font loading module or an X font server is in use.
Does the directory with that fonts.dir file show up in:
xset q
and is X's .../modules/fonts/libfreetype.so
69 matches
Mail list logo
