Re: [ft-devel] MSVC build woes !
Okay, here's my original Buildlog output text (in HTML format). I've packed it into a zip file this time because the first one was too big. Thanks again! I've again disabled MSVC warning C4127 in the git repository; especially after looking at https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines I now believe that the original solution of disabling this warning completely is the right thing. Theoretically, there shouldn't be any warnings now in an MSVC build. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype-devel post from john...@tiscali.co.uk requires approval
Werner LEMBERG w...@gnu.org writes:
After a bit more consideration I suspect it's simply the '0' in
while (0) that's causing all the warnings.
Is this really true? Can you check that explicitly? The `do{...}
while(0)' construction is extremely useful and so common that it
would make the MSVC warning completely useless.
Indeed so common that it can be called idiomatic in this usage (and
has been as long as I can remember).
Given it's idiomatic nature, it's pretty surprising that any widely
used compiler warns about it, even at maximum warning settings
-miles
--
Somebody has to do something, and it's just incredibly pathetic that it
has to be us. -- Jerry Garcia
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] MSVC build woes !
On 12/06/2013 10:10, Werner LEMBERG wrote: I've again disabled MSVC warning C4127 in the git repository; especially after looking at https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines I now believe that the original solution of disabling this warning completely is the right thing. Theoretically, there shouldn't be any warnings now in an MSVC build. Thanks for all your hard work Werner and for everybody's input on this. I only spotted one problem In 'ftserv.h' you've implemented the pragma like this:- #if defined( _MSC_VER ) /* Visual C++ (and Intel C++) */ /* We disable the warning `conditional expression is */ /* constant' in order to compile cleanly with the maximum */ /* level of warnings. */ #pragma warning( push ) #pragma warning( disable : 4127 ) #endif /* _MSC_VER */ // [ ... ] rest of header file #if defined( _MSC_VER ) #pragma warning( pop ) #endif But of course that doesn't work - because the 'pop' will re-enable the warning as soon as that header file finishes processing. By the time the compiler wends its way back to the original source file, warning 4127 is enabled again. The way you did it in 'ftdebug.h' works fine though. John ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Get_PS_Font_Private in CFF driver
Hi Werner, Okay, so in my specific case (CFF) the value is not used. I have been busy with other things, and was about to start making the change in the FreeType code that we talked about. But it's a little demotivating that the (required!) value is not used anyway... Thanks a lot for forwarding the Adobe communication though. Regards, Michael On 01/06/2013, at 14.48, Werner LEMBERG wrote: BTW, I've already received a `This is a good question' answer from Adobe, waiting for more to come :-) And here it is. The answer is far from trivial... Dave Arnold says that there are two cases where the StemV value is used (he wrote that from memory): . to select a font weight if a font substitution happens . to guide stem darkening for embedded TrueType fonts. Note that Adobe uses a special, self-made version of the TT interpreter which both handles stem darkening and artificial emboldening *before* hinting takes place. The StemV value is *not* used by the PDF engine if the embedded font is either a Type 1 or CFF font; in that case the value from the private dictionary gets used. For a CID font, the value associated with the glyph's font DICT gets used. In case there is no StemV value in the PDF, the following algorithm applies: . use a heuristic method to measure a particular glyph outline for getting a proper value . if that fails, use a default value (Dave believes it's 75 units) Similarly, this default value is used for CFFs which miss a StdVW operator. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Get_PS_Font_Private in CFF driver
Okay, so in my specific case (CFF) the value is not used. Yes, it seems that you can just add a dummy value. I have been busy with other things, and was about to start making the change in the FreeType code that we talked about. But it's a little demotivating that the (required!) value is not used anyway... :-) Thanks a lot for forwarding the Adobe communication though. Ah, this reminds me to rectify one remark: Note that Adobe uses a special, self-made version of the TT interpreter which both handles stem darkening and artificial emboldening *before* hinting takes place. This was faulty memory of mine: They actually use a special version of TT interpreter (it's a patched version of the MS interpreter), but stem darkening and embolding takes place *after* hinting. The darkening amount, however, needs to be fractional. The Adobe people implement this by disabling hints in the x-direction (which is disabled for the LCD mode anyway), applying darkening only in the x-direction. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
