Re: [ft-devel] Re: xorg crashes with freetype2-2.1.10

is intentional. I just upgraded to stock freetype 2.1.10 (was using cvs-2004-dec-31), went around a few web pages with mozilla-xft, and I don't have crashes. I am using xorg 6.8.2 on linux. How do you trigger the crash? Joe Marcus Clarke wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hin-Tak

Re: [ft-devel] Re: xorg crashes with freetype2-2.1.10

Joe Marcus Clarke wrote: On Wed, 2005-07-20 at 06:16 +0100, Hin-Tak Leung wrote: The ChangeLog entry does mention the specific change explicitly: Ah. Still kind of cryptic, though. _Why_ shouldn't they be used? Well, not entirely cryptic - seems to be a rewrite with an 'enhanced bitmap

Re: [ft-devel] Re: xorg crashes with freetype2-2.1.10

Joe Marcus Clarke wrote: On Wed, 2005-07-20 at 07:02 +0100, Hin-Tak Leung wrote: Joe Marcus Clarke wrote: snipped Ours is autogenerated by ttmkfdir. You might fine some helpful hints on crashing X from this thread: http://forums.gentoo.org/viewtopic-t-359535-highlight-aalib.html?sid

Re: [ft-devel] Re: xorg crashes with freetype2-2.1.10

Jeremy Messenger wrote: snipped I have played with it more to find a good way to reproduce it. Well, kind of. Download crash.txt, then view in Firefox (maybe works for Mozilla too). Be sure to save anything before you play with crash.txt, because it will kill X.

Re: [ft-devel] Re: xorg crashes with freetype2-2.1.10

Jeremy Messenger wrote: On Wed, 20 Jul 2005 00:39:56 -0500, Joe Marcus Clarke snipped Okay, I have played with it more.. Guess what? Hin-Tak is right about rename the name do cause the trouble for freetype2 2.1.10 with no patch. The old freetype2 do accept the rename but not now in

Re: [ft-devel] Re: xorg crashes with freetype2-2.1.10

Werner LEMBERG wrote: For me xorg 6.8.2 crashes with freetype-2.1.10 when I try to run xterm -font -monotype-courier new-medium-r-normal--20-0-0-0-m-0-koi8-r Yes, I can finally(?) crash my x-server with this as well. Can you produce a backtrace? Here is the backtrace. It looks the same as

Re: [ft-devel] Re: xorg crashes with freetype2-2.1.10

Werner LEMBERG wrote: Here is the backtrace. It looks the same as the initial report though. Thanks. This assures that it is the same bug, and not a different one. I think that David Turner is back from vacation soon, and hopefully Keith Packard too. Let's wait what they have to say. I'm

Re: [ft-devel] multithreading and 64 bits

PILLET Céline wrote: Hello. I am using FreeType Library. Do you think FreeType work with multithreading? One FT_Library for each thread?? Do you think FreeType work with 64 bits sytem configuration? I do not know the answer for certain to the first question... but the 2nd question - you do

Re: [ft-devel] multithreading and 64 bits

Yes, I got bitten by it in ghostscript a few months ago in the freetype dervied code. long on win64 is indeed 32-bit - one needs long long to get a 64-bit wide integer type on win64, unlike the case on most 64-bit unices. --- Tom Kacvinsky [EMAIL PROTECTED] wrote: The long integer type on

Re: [ft-devel] invalid magic number in TTF

Werner LEMBERG wrote: I only have one issue with freetype 2 at the moment - ftdump (or ftview) on NISC18030.ttf, one of the fonts shipped with Mac OS X 10.7 (and possibly other versions also) don't work. I haven't looked much further, but ghostscript seems to be happy loading the font file,

Re: [ft-devel] invalid magic number in TTF

Werner LEMBERG wrote: Thanks, Werner. ftdump now works, but ftview still doesn't - a red Invalid Pixel size at the top. Change the pixel size until you get a fitting one :-) Tip: it's a 16x16 bitmap. Indeed. :-). This is the first time for me where the command line ppem parameter mattered

[ft-devel] advance width info in one of the ft* demo's (Fwd: Re: [tlbuild] ttf2pk versus ttf2pk2)

Subject: Re: [tlbuild] ttf2pk versus ttf2pk2 Date: Tue, 06 Aug 2013 11:51:33 +0100 From: Hin-Tak Leung ht...@users.sourceforge.net snipped - according to freetype 1's ftmetric, libs/freetype/freetype-1.5/test/ftmetric -i 100 10 some.font.ttf There are 1 fonts in this collection

[ft-devel] A few more problematic fonts

Hi, Here are a few more problematic fonts: doesn't load: http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/ports/distfiles/zh-wangttf/WCL-02.ttf (Earlier versions of this do, so it is a case of caullous modifications). Three fonts which seems to only work correctly at specific sizes: (try

Re: [ft-devel] Windows x64 Build Re: Freetype-devel Digest, Vol 105, Issue 12

Just wish to point out that a copy of the whole of freetype is bundled with ghostscript, and ghostscript has been routinely built for win64 for quite a few years. For as long as it was, the preferred compiler for building ghostscript for windows has always been MS VC. If you ask nicely, the

[ft-devel] ftdump filepath length limit (Re: A few more problematic fonts)

, but maybe you know where it is. ftview is okay with the long name, so it is a bit curious. (The long path is a usb drive I have moved rarely-used or archive stuff to...). Hin-Tak Leung wrote: Just resending - I think this may have 'fallen through the crack' when you were attending a course in mid

Re: [ft-devel] A few more problematic fonts

-- On Wed, Nov 20, 2013 20:06 GMT Werner LEMBERG wrote: [Infinality, please read that! I need your help.] Just resending - I think this may have 'fallen through the crack' when you were attending a course in mid-August. Thanks :-) doesn't load:

Re: [ft-devel] A few more problematic fonts

-- On Thu, Nov 21, 2013 05:44 GMT Werner LEMBERG wrote: You already fixed this one - this was the one with the long path for ftdump.  Thanks.  128 Bytes was really too low - only windows CDs have 128 unicode char limit these days... I think linux's is at least

Re: [ft-devel] A few more problematic fonts

On Thu, 21/11/13, Werner LEMBERG w...@gnu.org wrote: This, however, is a bug in the font itself: It sets its embedded bitmap type to value 7 (bit-aligned), while the data is type 6 (byte-aligned).  I've fixed this in the git repository also so

Re: [ft-devel] A few more problematic fonts

-- On Sat, Nov 23, 2013 23:21 GMT Werner LEMBERG wrote: Mostly it looks alright now, except the first couple of lines of bitmaps (basically the ASCII's, A-Za-z0-9). A typo, fixed now. Thanks for spotting. About the other remaining issue in this thread - v38

Re: [ft-devel] A few more problematic fonts

-- On Sun, Nov 24, 2013 08:17 GMT Werner LEMBERG wrote: The hk gov fonts seem to have the strange property that some glyphs look antialiased while others look bitmapped - is that because of partial bitmap coverage ( i. e. Not all glyphs have bitmaps)? Yes. In

Re: [ft-devel] A few more problematic fonts

-- On Sun, Nov 24, 2013 11:45 GMT Werner LEMBERG wrote: Is it difficult to make the bitmap toggle cycle through bitmap+outlinefallback, bitmaponly, outlineonly? Not really, but I don't see the benefit. It's quite obvious which glyphs are represented by a bitmap,

[ft-devel] couple of new issues with 2.5.1

Hi Werner, Found two new issues with 2.5.1 (vs 2.5.0): - ftgrid in demos now fails to compile due to missing symbol when freetype itself is built in release mode. It used to work in 2.5.0. I found the commit which broke this was: commit fb964cdcd8fddd7722826379c28bcbece7b1d8fd Author: Werner

Re: [ft-devel] couple of new issues with 2.5.1

-- On Tue, Nov 26, 2013 11:36 GMT Werner LEMBERG wrote: - ftgrid in demos now fails to compile due to missing symbol when freetype itself is built in release mode. It used to work in 2.5.0. Uh, oh, for me it compiles just fine, using gcc 4.7.2. What commands did

Re: [ft-devel] couple of new issues with 2.5.1

-- On Wed, Nov 27, 2013 11:30 GMT Werner LEMBERG wrote: 'make devel' does debug mode? Yes.  I have forgotten to test compilation of the demo programs in non-debug mode, sorry. I've now fixed the issue (which was non-trivial).  Thanks to all reporters, please test.

[ft-devel] freetype on mac os X question/curious comments.

Hi Werner, I seem to recall that you don't have much access to Mac OS X; nonetheless, I wonder if you have an idea what's the context of two curious comments in some source code I came across with (it is the cairo bridge code in R, if you want to know). This concerns Mac OS X's shipping

Re: [ft-devel] freetype on mac os X question/curious comments Re: Freetype-devel Digest, Vol 107, Issue 10

Hi, I guess it is related with the handling of Suitcase format font. Please let me check. Regards, mpsuzuki Thanks for the offer. If you are interested in that bit of code snipplet in context, or the rest of it, it is in the middle of

[ft-devel] broken includes and ftversion from freetype-config in 2.5.2

Hi Werner, Looks like a few freetype2 should be removed from freetype-config: $ pkg-config --variable includedir freetype2 /usr/include/freetype2 $ freetype-config --cflags -I/usr/include/freetype2/freetype2 since pkg-config --variable includedir freetype2 already put $includedir right, some

Re: [ft-devel] broken includes and ftversion from freetype-config in 2.5.2

--variable libdir freetype2` enable_shared=%build_libtool_libs% usage() = Wouldn't something like this makes sense also? In a way this makes freetype-config cross-compile aware, this pkg-config is sensitive to whether it is being run in a cross-compile environment. Hin-Tak Leung

Re: [ft-devel] broken includes and ftversion from freetype-config in 2.5.2

Are you sure? I think $PKG_CONFIG_LIBDIR is already part of standard pkg-config, although --host isn't, according to this: http://www.freedesktop.org/wiki/Software/pkg-config/CrossCompileProposal/ On Sun, 22/12/13, Werner LEMBERG w...@gnu.org wrote:

Re: [ft-devel] freetype on mac os X question/curious comments Re: Freetype-devel Digest, Vol 107, Issue 10

to enable/disable the fragmented resources. The switch is enabled only for PostScript Type1 in Suitcase. An internal header (ftrfork.h) is modified, but I think there is no impact except of the rogue client using the internal header. Regards, mpsuzuki (13/12/20 14:04), Hin-Tak Leung wrote

[ft-devel] A few compiler warnings from Mac OS's gcc.

Hi Werner, There are a few warnings from an old Mac OS X's compiler, You might want to look into them? The long long seems to be harmless - but I am somewhat surprised you have a warning suppression for gcc 4.6(?) near one of these - the compiler itself reports itself as (GCC) 4.2.1 (Apple Inc.

[ft-devel] IMP- Regarding FT_Set_Transform Re: Freetype-devel Digest, Vol 118, Issue 5

Can you apply the reverse transform after use, before the next usage? On Thu, 13/11/14, freetype-devel-requ...@nongnu.org freetype-devel-requ...@nongnu.org wrote: Message: 1 Date: Thu, 13 Nov 2014 19:19:17 +0530 From: tauseef tauseef...@gmail.com

[ft-devel] a couple of warnings from 2.5.4 with mingw/darwinx

Hi, am trying to build a more current-ish freetype for mingw and darwinx after a while (I did that around 2.4.10-2.5.2 somewhat regularly - apparently I haven't done that for about a year...) - and apology if these are already fixed in latest git - I guess putting it down and say it is fixed, is

[ft-devel] sign in conversion INT_MIN and FT_Render_Glyph (Re: Freetype-devel Digest, Vol 121, Issue 4)

I suggest putting #define INT_MIN ((signed) 0x8000) and see if there is any warnings anywhere, for any compilers, on a trial/testing basis. This might catch some interesting and hidden bugs. BTW, mingw header defines it in include/limits.h as: #define INT_MIN (-2147483647 - 1) There

Re: [ft-devel] sign in conversion INT_MIN and FT_Render_Glyph (Re: Freetype-devel Digest, Vol 121, Issue 4)

wrote: On Fri, Feb 13, 2015 at 1:45 PM, Hin-Tak Leung ht...@users.sourceforge.net wrote: This might catch some interesting and hidden bugs. BTW, mingw header defines it in include/limits.h as: #define INT_MIN (-2147483647 - 1) Freetype does not redefine *standard* INT_MIN

[ft-devel] about that C# fontval (Re: Freetype-devel Digest, Vol 125, Issue 10)

Does anybody know if the C#-based fontval compiles and runs with mono yet? I see Microsoft had made many contributions to mono in recent years, but it still isn't true that any C# based programs buildable with MS's C# compiler will build with mono's, nor runnable where mono runs (which includes

Re: [ft-devel] about that C# fontval (Re: Freetype-devel Digest, Vol 125, Issue 10)

On Wed, 10/6/15, Behdad Esfahbod behdad.esfah...@gmail.com wrote: On 15-06-10 02:43 PM, Hin-Tak Leung wrote: If it works with mono, then there is a better chance of it getting contributed enhancements, than if it only works with MS C#/.net

[ft-devel] possibility of optimizing for speed with device metrics

Hi Werner, I am going through some of our earlier private e-mails on the new FT_LOAD_COMPUTE_METRICS introduced in freetpe 2.6.1 and remember something from my testing - I was surprised that adding that make no noticeable difference to speed. Then I looked at the code, and see that Freetype does

Re: [ft-devel] DSIG - Re: Freetype-devel Digest, Vol 130, Issue 8

-- On Tue, Nov 10, 2015 4:21 AM GMT Werner LEMBERG wrote: > > But I think signing is a good thing - not from the security point > of view, but of making font designers (or rather, font modifiers) > less callous about doing ad hoc modification of fonts. I think >

[ft-devel] Microsoft Font Validator open-sourced under the MIT license!

Dear all, I am glad the cat is finally out of the bag: https://github.com/Microsoft/Font-Validator and all the stuff I have added are in: https://github.com/HinTak/Font-Validator Mono on non-windows can be used to build and run it. It is mainly being worked on on Linux, but known to work on

[ft-devel] DSIG - Re: Freetype-devel Digest, Vol 130, Issue 8

-- On Mon, Nov 9, 2015 8:44 AM GMT Behdad Esfahbod wrote: >On 15-11-05 11:29 AM, Hin-Tak Leung wrote: >> Also, rather strangely Si Daniels of Microsoft doesn't know that >> microsoft's font signing tool package also ships a signature checking tool. >

Re: [ft-devel] DSIG - Re: Freetype-devel Digest, Vol 130, Issue 8

-- On Mon, Nov 9, 2015 11:14 PM GMT Behdad Esfahbod wrote: >On 15-11-09 02:42 PM, Hin-Tak Leung wrote: >> -- >> On Mon, Nov 9, 2015 8:44 AM GMT Behdad Esfahbod wrote: >> >> On 15-11-05 11:29 AM, Hin-Tak Le

Re: [ft-devel] DSIG - Re: Freetype-devel Digest, Vol 130, Issue 8

-- On Mon, Nov 9, 2015 11:14 PM GMT Behdad Esfahbod wrote: >On 15-11-09 02:42 PM, Hin-Tak Leung wrote: >> -- >> On Mon, Nov 9, 2015 8:44 AM GMT Behdad Esfahbod wrote: >> >> On 15-11-05 11:29 AM, Hin-Tak Le

Re: [ft-devel] Freetype-devel Digest, Vol 130, Issue 8

... From: Markus Trippelsdorf ... Subject: Re: [ft-devel] Hinting paths Message-ID: <20151105164556.GC325@x4> ... There is a nice summary of the recent ATypI conference on LWN today: http://lwn.net/SubscriberLink/662813/4795feb3a4ac97d2/ ... Interesting reading.

[ft-devel] Support standardized CBDT/CBLC Re: Freetype-devel Digest, Vol 129, Issue 10

Hi Behdad, do you have such a font and/or can point me in the direction of one such file? I'll add support for that to the TODO list of you-know-what :-). It doesn't currently parse those those tables, at all. I assume that's because color glyphs is a recent (>2009) addition. Hin-Tak Message:

Re: [ft-devel] Builind for windows Re: Freetype-devel Digest, Vol 131, Issue 16

What is the exact message for the unresolved symbol? It might be an obvious question, but you know that there are different versions of the window platform SDKs, right? I have win 7, and there is a win 7.1, and the two are different. The platform SDKs are separate downloads from visual studio

[ft-devel] Slightly off-spec opentype CFF fonts shipped in os X Yosemite

Two fonts in OS X Yosemite (maybe other versions also), YuppySC-Regular.otf and YuppyTC was apparently made in 1996 (according to the copyright notice) and have not been updated, and uses the obsolete 'ForceBoldThreshold' key in the private dictionary inside the CID font dict array. The key was

[ft-devel] proposed enhancement to freetype for truetype diagnostics.

Hi, An earlier version of some of this was sent to Werner privately yesterday. I thought a bit more, and posted it as: https://github.com/HinTak/Font-Validator/issues/5#issuecomment-182210815 So this is a head-up that something will happen in that direction. Hin-Tak === Implementing the whole

[ft-devel] non-ascii in String INDEX of CFF opentype table

encoded. Any comments? On Tue, 26/1/16, Hin-Tak Leung <ht...@users.sourceforge.net> wrote: ... what next - from the newest and latest SVG table, I have turned to having a look at the oldest unsupported one - CFF. Microsoft did not implement a

Re: [ft-devel] non-ascii in String INDEX of CFF opentype table

-8 with each byte octal-escaped. Or it could (?) be just declared that direct UTF-8 with parantheses escapement is fine. PostScript string escaping conventions: http://www.tailrecursive.org/postscript/escapes.html A. Sent from my mobile phone. > On 31.01.2016, at 03:45, Hin-T

[ft-devel] Microsoft Font Validator adds SVG checking, and 2nd Mac OS X native release

2016-01-22 was tagged on github ( https://github.com/HinTak/Font-Validator ). Code snapshots (-src-*), mono/.net binaries (*-bin-*) and Mac OS X disk images (*.dmg) are at: http://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft Font Validator/ Compared to the last (2016-01-06), there

[ft-devel] bug report: ftview on Apple Emoji spins on render mode 5

Hi, I was just playing around with ftview, and pressing space bars a few times with: ftview 40 'Apple Color Emoji.ttf' mode 4 (stroke) shows error 0x0024, then another press on space bar, ftview goes into a spin. It would have been mode 5 (text string), I think. This is all 2.6.3. # md5sum

[ft-devel] KaiU (Re: Freetype-devel Digest, Vol 135, Issue 1)

Thanks, Werner and Suzuki San, for the detailed explanations! I was trying to grab some screen shots for my talk next week for with/without hinting - in the end, I switched to using MS Mincho instead. Page 16/17 http://htl10.users.sourceforge.net/tmp/FontVal-LG2016.pdf , if you are curious.

Re: [ft-devel] bug report: ftview on Apple Emoji spins on render mode 5

On Fri, 8/4/16, Werner LEMBERG wrote: > It was a bug in ftview.  Fixed in git, and thanks for the report! That was quick - thanks a lot! Hin-Tak ___ Freetype-devel mailing list

[ft-devel] The KaiU.ttf anomaly.

Werner, It is not possible to toggle hinting with either MingLiU or KaiU in ftview, right? I seems to remember many years ago before hinting was implemented/enabled, they looks very bad - now that I understand hinting a lot more, I think the problem with them is that they do very "creative"

[ft-devel] ft2demos with X11 on OS X (XQuartz) (Re: Freetype-devel Digest, Vol 134, Issue 22)

do you have multiple versions of some libraries (possibly freetype) under both /opt/X11/lib and /usr/local/lib ? Possibly also cairo, etc? The X server should be launched on demand by launchd, but it does depend on you trying to access those versions of libraries under /opt/X11, and not other

Re: [ft-devel] ft2demos with X11 on OS X (XQuartz) (Re: Freetype-devel Digest, Vol 134, Issue 22)

The library dependence is likely dynamic... you could examine which copy of the library it is trying to load by: otool -L To some extent, you can override it with: export DYLD_LIBRARY_PATH=/opt/X11/lib before you run the binary, but this is generally frown upon, as other things may break.

Re: [ft-devel] ft2demos with X11 on OS X (XQuartz) (Re: Freetype-devel Digest, Vol 134, Issue 22)

Oh, it is possible to modify binary, after build, to embed specific library locations using install_name_tool . see http://www.unix.com/man-page/osx/1/install_name_tool/ On Sat, 26/3/16, Hin-Tak Leung <ht...@users.sourceforge.net>

[ft-devel] verdanab.ttf (Re: Freetype-devel Digest, Vol 133, Issue 17)

I have version 2.40 and 5.02 (as well as 2.35) in case you want to see smaller differences... -- Date: Mon, 15 Feb 2016 06:36:47 +0100 (CET) From: Werner LEMBERG Running current git on `verdanab.ttf', version

[ft-devel] Freetype's fedora maintainer contact (Re: Freetype-devel Digest, Vol 133, Issue 19)

It looks like fedora 24 will ship freetype 2.6.3 at least: http://koji.fedoraproject.org/koji/packageinfo?packageID=313 This is fedora's build farm url. If you need an actual person(s) to contact, the e-mails in the Changelogs would probably do:

Re: [ft-devel] Font Validator 2.0, and libre font test results

Hi, Just to recap, as part of the effort leading up to Font Validator 2.0, I tested all the fonts I have in my processsion on both 2.0 and 1.0, at just size 10, for B/W rendering (the full run is about 70 sizes from 4 to 126, and B/W + gray + subpixel rendering, and obviously will take about

[ft-devel] glyf (i.e. contour) analysis reports on libre fonts.

Hi, People who went to LGM 2016 London in April this year and heard my talk would hear that, IMHO, the most unique and valuable part of the Font Validator is its analysis on individual glyphs. That is broadly divided into the glyf table test on the glyph contours, and the rasterization test on

Re: [ft-devel] The new v40 interpreter

On Tue, 2/8/16, Werner LEMBERG wrote: > > I wondered whether I should hook up v38 instead, or in addition. > > Speed is definitely not a concern for a tool that uses private > > version of FreeType to analyze fonts - it will just take

Re: [ft-devel] [CREATE] glyf (i.e. contour) analysis reports on libre fonts.

On Fri, 12/8/16, peter sikking wrote: > Dave Crossland wrote: > > Thanks Hin-Tak! You did an amazing thing in the last year :D > hear hear. this kind of work can be rather thankless, so I hope that Hin-Tak is getting enough

[ft-devel] Font Validator 2.0, and libre font test results

Hi, It is a bit like the Mac OS X native binaries - it took a long time to get the command-line to work, then another week later, the GUI follows. So last weekend the rasterization test (which tests for truetype hinting instructions) which Microsoft did not release, got the beginning of an

Re: [ft-devel] error enums that I _cannot_ add

Argh, my question was meant to be "can you give me some hints how to add those" :-). I added the 64k limit myself - that was b52/b53 - line 3715 and 4010, after the "case 0x2D" lines: ( http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/truetype/ttinterp.c ) insert something

Re: [ft-devel] GETVARIATION and GETDATA

> > There is a GETDATA instruction also... > GETDATA?  Never heard of.  Do you have details? You have heard of it, from me :-). I asked you about a year ago about the old Font Validator complaining a few microsoft fonts containing apple instructions. You said the report was bogus. It

Re: [ft-devel] GETVARIATION and GETDATA

> > GETDATA?  Never heard of.  Do you have details? I dug up the e-mail from my out box. It was titled "Re: FontVal-dev slide Fw: Linux VM & CPU resources for font testing" Sunday, 25 October, 2015 16:22 to you and Behdad only; but with both of the font files, as well as the font report

Re: [ft-devel] GETVARIATION and GETDATA

Sorry, I think the 17 (or pushing one value onto the stack) is wrong. I just added that push, and now I get piles and piles of instruction under flow errors, analysing those two fonts. Assuming the font is mostly correct and intended to work correctly on apple platform...

Re: [ft-devel] GETVARIATION and GETDATA

On Sun, 17/7/16, Werner LEMBERG wrote: > I won't add this until I have more details; maybe you can contact someone from Apple? Well, somebody on this list from apple can speak up :-). For you, the only thing that matter is the 2nd

Re: [ft-devel] GETVARIATION and GETDATA

On Sun, 17/7/16, Werner LEMBERG wrote: > OK, added to git.  Behdad says this always returns 17, so the implementation was trivial. Oh, I though Behdad was just being humorous about 42 / 17? > Please send me the LaoUI.ttf version

Re: [ft-devel] GETVARIATION and GETDATA

On Sun, 17/7/16, Werner LEMBERG wrote: > And now I remember again: The font is OK, there are *no* undocumented instructions at all!  It properly uses IDEF everywhere.  While unusual, this is fully valid bytecode, even on MS engines. 

[ft-devel] GETVARIATION and GETDATA (Re: Freetype-devel Digest, Vol 138, Issue 24)

> I've just added support for the completely undocumented (but confirmed) `GETVARIATION' bytecode instruction ? now instances from Skia.ttf get hinted correctly! There is a GETDATA instruction also... Argh, I have just tagged and built b53 for Font validator 2.0 , and pushed it out. Need

Re: [ft-devel] GETVARIATION and GETDATA

On Sun, 17/7/16, Behdad Esfahbod wrote: ...This is to make the Chinese fonts that draw the glyph in their hint instructions to work.  which one, and what vintage? You may not notice, but I did run the font validator on all

Re: [ft-devel] proposed patch for diagnostics (Re: implementing detection of hinting/rasterization errors in fonts)

On Mon, 4/7/16, Behdad Esfahbod wrote: > The use of a global variable is not desirable.  Put it on the FT_Library at least. I sort of thought about that for a bit - it would be a ABI breakage, expanding existing

[ft-devel] updated patch for 2.6.4 Re: proposed patch for diagnostics (Re: implementing detection of hinting/rasterization errors in fonts)

Here is the updated patch for 2.6.4 - there are some minor collisions with the new subpixel hinting mode. while updating the diff I looked into the global variable issue. Putting the diagnostic messaging pointer inside TT_Face is fairly straight forward, and it isn't too hard to do it per

Re: [ft-devel] Something in 2.6.4 broke my windows (Re: Freetype-devel Digest, Vol 138, Issue 9)

it is just this: === commit ea9763c8ec26dd009121afae27823c7cf5fe5386 Author: Hin-Tak Leung <ht...@users.sourceforge.net> Date: Wed Jul 6 02:13:19 2016 +0100 Do not switch on subpixel-hinting even if compiled in diff --git a/src/truetype/ttobjs.c b/src/truetype/ttobjs.c index ed3be2d..fb4dc63 100644 --- a/src/tr

[ft-devel] 2.6.4 mac build breakage (Re: Something in 2.6.4 broke my windows (Re: Freetype-devel Digest, Vol 138, Issue 9))

On Thu, 7/7/16, Hin-Tak Leung <ht...@users.sourceforge.net> wrote: > From: Werner LEMBERG <w...@gnu.org> > > What do you think?  Due to a linking problem on OS X I have to release a new FreeType version quite

Re: [ft-devel] 2.6.4 mac build breakage (Re: Something in 2.6.4 broke my windows (Re: Freetype-devel Digest, Vol 138, Issue 9))

On Thu, 7/7/16, suzuki toshiya wrote: > Sorry for your inconvenience. The bug was reported at https://savannah.nongnu.org/bugs/?48417 and I've committed a patch and testing tarball was uploaded at savannah. Please test,

[ft-devel] fontconfig (Re: Something in 2.6.4 broke my windows)

On Fri, 8/7/16, Werner LEMBERG wrote: > I think you have a fundamental misunderstanding of how fontconfig > works.  This library is only used to find a best matching font for a > given set of constraints... I don't mean to be

Re: [ft-devel] fontconfig (Re: Something in 2.6.4 broke my windows)

On Fri, 8/7/16, Alexei Podtelezhnikov wrote: > I hate this argument so deeply! I do not know a single distribution that updates FreeType between their major releases. Most distribution still ship very old version. I do not

[ft-devel] The new Font Validator with rasterization (i.e. hinting) test out now!

Hi, I am happy enough with it, so it is out. About 20% of microsoft's own shipped fonts on win 8 show some degree of problems in this area, and most of them are genuine (although as some suspected, the older 2003 Font Validator is occasionally buggy...). It is just that rendering engines

[ft-devel] desktop-wide freetype setting Re: Something in 2.6.4 broke my windows

On Thu, 7/7/16, Werner LEMBERG wrote: > I disagree.  The above *is* a clean, system-wide solution.  Right now, there is no possibility by a user (or by the system administrator) to influence the default rendering setup of FreeType

Re: [ft-devel] Something in 2.6.4 broke my windows

On Thu, 7/7/16, Werner LEMBERG wrote: > >  FREETYPE_PROPERTIES=truetype:interpreter-version=35 \ >                      cff:no-stem-darkening=1 \ >                      autofitter:warping=1 > > The original poster appears to want

Re: [ft-devel] Something in 2.6.4 broke my windows

On Thu, 7/7/16, Werner LEMBERG wrote: > ...  It only *returns* the font configuration, as far as I know; it *does not set* font configuration parameters. It does set font configuration parameters. Just grep'ed through

Re: [ft-devel] updated patch for 2.6.4 Re: proposed patch for diagnostics

Thanks for reviewing and revising the patch. I'd likely just use your patch instead, when I do the win32/64 and mac os x binaries in the next couple of days. Right now I still have a few things to do on the C# side. I thought about the enum vs string issue (FT_DIAG_XXX) a bit, as I mentioned at

Re: [ft-devel] updated patch for 2.6.4 Re: proposed patch for diagnostics

On Wed, 6/7/16, Graham Asher wrote: > Please consider calling it ftdiagnostics.h, which is more explanatory. To my native-English-speaking mind, 'diag' looks as if it stands for 'diagonal' or

[ft-devel] Fw: Re: GETVARIATION and GETDATA

--- On Mon, 8/8/16, Alexei Podtelezhnikov <apodt...@gmail.com> wrote: > On Tue, Aug 2, 2016 at 1:32 > AM, Hin-Tak Leung <hintak_le...@yahoo.co.uk> > wrote: > the apple > font editor in that era seems to be capable of using > GETDATA! > > > Two more

Re: [ft-devel] GETVARIATION and GETDATA

On Mon, 8/8/16, Alexei Podtelezhnikov wrote: > After stringing a lot of old MacOS executables, RoyalT seems to be the only one with GETDATA diagnostics. It is certain that GETDATA took some selector. Perhaps it is possible to

Re: [ft-devel] GETVARIATION and GETDATA

On Sun, 7/8/16, Werner LEMBERG wrote: > > It appears that the apple font edior of that era, RoyalT, is capable > of manipulating the GETVARIATION and GETDATA instructions. > Interesting.  It would be definitely worth to get this

Re: [ft-devel] GETVARIATION and GETDATA

On Sun, 7/8/16, Alexei Podtelezhnikov wrote: > If it quacks like a duck and walks like a duck... Could GETDATA be just an early version of GETINFO back then? Possibly not. RoyalT already had GETINFO then. I am just doing

Re: [ft-devel] GETVARIATION and GETDATA

> This is to make the Chinese > fonts that draw the glyph in their hint instructions to work.  So, > you can grab one of those and modify to inspect the return value of > this instruction. Behdad, Do you have any reference/names for those fonts? I have extracted all the fonts shipped on

Re: [ft-devel] implementing detection of hinting/rasterization errors in fonts

On Sat, 2/7/16, Werner LEMBERG wrote: > I have started testing the new implementation of rasterization tests > in font validator (background, planned in > https://github.com/HinTak/Font-Validator/issues/5 ) and comparing > how

Re: [ft-devel] implementing detection of hinting/rasterization errors in fonts

ors (still nearly 60 to go!) are simply silently worked around also. On Sat, 2/7/16, Hin-Tak Leung <ht...@users.sourceforge.net> wrote: ...     /* at small sizes, F_dot_P can become too small, resulting   */     /* in overflows and `spi

[ft-devel] implementing detection of hinting/rasterization errors in fonts

Hi Werner, I have started testing the new implementation of rasterization tests in font validator (background, planned in https://github.com/HinTak/Font-Validator/issues/5 ) and comparing how the new test behaves, with the old 2003 binary. Specifically, about line 7193 of here - (is line 6619

Re: [ft-devel] implementing detection of hinting/rasterization errors in fonts

On Sat, 2/7/16, Werner LEMBERG wrote: > > I found that bit of code inside Compute_Func when I was looking for > > other examples of manipulating those same variables to simplify my > > error detection code inside Direct_Move . It is

Re: [ft-devel] implementing detection of hinting/rasterization errors in fonts

-- On Sun, 3/7/16, Hin-Tak Leung <ht...@users.sourceforge.net> wrote: Please ignore the 2nd question - it is just "exc->is_composite" ! ------------ On Sun, 3/7/16, Hin-Tak Leung <ht...@users.sourceforge.net> wrote: T

Re: [ft-devel] implementing detection of hinting/rasterization errors in fonts

Please ignore the 2nd question - it is just "exc->is_composite" ! On Sun, 3/7/16, Hin-Tak Leung <ht...@users.sourceforge.net> wrote: Hi, I had a look at the other errors showed by analysing win8.1 shipped fonts with the 2003 b

Re: [ft-devel] implementing detection of hinting/rasterization errors in fonts

Hi, I had a look at the other errors showed by analysing win8.1 shipped fonts with the 2003 binary, and updated "https://github.com/HinTak/Font-Validator/issues/5; with some details. Anyway, the summary is this: Out of the 7 kinds of errors/warnings that the 2003 binary can find with win 8.1

[ft-devel] proposed patch for diagnostics (Re: implementing detection of hinting/rasterization errors in fonts)

Hi Werner, Here is likely the final form of mod to freetype that I am putting in as part of the next release of font validator. Mostly it is just two new APIs : to set and unset an external diagnostics messaging routine, and a macro which wrap around it to call it in a nicer way:

  1   2   3   4   >