Re: [ft-devel] CPAL interface

[Alexei Podtelezhnikov]

On Fri, May 18, 2018 at 5:11 AM, Werner LEMBERG  wrote:
>
>>> I think that FreeType should provide a single, most basic solution
>>> for convenience – it's really just a few lines of code.
>>
>> Lets do it properly then.  Let's blend a layer or a glyph (in color)
>> onto an arbitrary background image with gamma correction.  I just
>> checked that finite difference approximation for gamma ramps works
>> pretty good.
>
> OK.  How would an API look like?

FT_Library_SetGamma
would initialize two 256-byte look up tables in FT_LibraryRec
so that instead of power functions we could do library->gamma[red].

FT_Blend_Glyph(FT_Bitmap target,
FT_GyphSlot source,
   FT_Color color
FT_Vector topleft )

target must be  FT_PIXEL_MODE_BGRA
source must be FT_GLYPH_FORMAT_BITMAP
if topleft is not rounded,  we can try to blend with a subpixel shift

you can start from any target but you need to blend layers sequentially.

> Note that blending onto an arbitrary background image is not necessary
> IMHO.  I think the ultimate goal is to return color glyph images to
> the client that have the same format as colored bitmaps from the
> `CBDT' table.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC

[John Emmas]

On 18/05/2018 15:30, Alexei Podtelezhnikov wrote:


Do you use our stock project file? Could there be an option to
enable/disable intrinsics? Please investigate it.



Oh wow... very well spotted !

I'm using my own VC project file where instrinsic functions were 
disabled.  Enabling that option allows me to build without errors - even 
from the earlier git version (i.e. before Werner added the test for 
VS2013).  So with intrinsic functions enabled, that test isn't needed 
(though the underscored __inline is still needed, of course...)


I don't use your stock projects but it looks like the one for VC2010 has 
intrinsics enabled.  AFAICT though, the others are simply using the 
default setting which I'd assume is (most likely) disabled. Thanks again,


John

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC

[Alexei Podtelezhnikov]

On Fri, May 18, 2018 at 9:30 AM, John Emmas  wrote:
> On 18/05/2018 14:00, Alexei Podtelezhnikov wrote:
>>
>>
>> Actually since VS2005
>> https://en.wikipedia.org/wiki/Find_first_set
>>
>> and references therein.
>>
>
> Hmmm, the plot thickens... I'm using VS2005 which doesn't find it - although
> 'intrin.h' defines it like this:-

Do you use our stock project file? Could there be an option to
enable/disable intrinsics? Please investigate it.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC

[John Emmas]

On 18/05/2018 14:00, Alexei Podtelezhnikov wrote:


Actually since VS2005
https://en.wikipedia.org/wiki/Find_first_set

and references therein.



Hmmm, the plot thickens... I'm using VS2005 which doesn't find it - 
although 'intrin.h' defines it like this:-


__MACHINEIW64(unsigned char _BitScanReverse(unsigned long* Index, 
unsigned long Mask))


So I wonder if it was initially only available for 64-bit compilation, 
then later got ported to 32-bit??


Also, it's MSDN entry doesn't specify that any link lib is needed so 
I've been assuming it gets implemented as a macro (?)


John

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC

[Alexei Podtelezhnikov]

On Fri, May 18, 2018 at 4:58 AM, Werner LEMBERG  wrote:
>
>> Fixing that issue has simply highlighted another problem five lines
>> later, namely:-
>>
>>   _BitScanReverse ( %where, x );
>>
>> Bear in mind that Visual Studio didn't introduce _BitScanReverse
>> until VS2013 (MSDN says VS2010 but I think that's wrong).

Actually since VS2005
https://en.wikipedia.org/wiki/Find_first_set

and references therein.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC

[John Emmas]

Seems to be building fine again now, thanks...

On 18/05/2018 09:58, Werner LEMBERG wrote:

I see a question about `BitScanReverse' on stackoverflow
asked in December 2011...

   
https://stackoverflow.com/questions/8626891/bitscanforward64-issue-in-visual-studio-11-developer-preview

On the other hand, it doesn't really matter :-)



Ah, okay - I was only going by the fact that its MSDN entry is dated 
early in 2013 so I assumed it (maybe?) got introduced towards the end of 
VS2012.


Thanks for all your help with this,

John

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC

[Werner LEMBERG]

> Fixing that issue has simply highlighted another problem five lines
> later, namely:-
> 
>   _BitScanReverse ( %where, x );
> 
> Bear in mind that Visual Studio didn't introduce _BitScanReverse
> until VS2013 (MSDN says VS2010 but I think that's wrong).

Really?  I see a question about `BitScanReverse' on stackoverflow
asked in December 2011...

  
https://stackoverflow.com/questions/8626891/bitscanforward64-issue-in-visual-studio-11-developer-preview

On the other hand, it doesn't really matter :-)

> Either way, the above change has made freetype2 unbuildable now
> with anything earlier :-(

Thanks, should be fixed in git now.  Please test.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] CPAL interface

[Alexei Podtelezhnikov]

On Fri, May 18, 2018 at 1:18 AM, Werner LEMBERG  wrote:
>
>>> Not for this case, as far as I can see.  The code to blend two
>>> color layers as specified in COLR/CPAL is (currently) function
>>> `tt_face_colr_blend_layer'.
>>
>> I strongly suggest that this is removed.  Linear blending is bad
>> anyway.  We should just provide coverage maps for each layer
>> (including MONO and LCD optimized ones) and let client libraries
>> with good gamma-corrected blending do the final assembly job.  We
>> stayed away from blending and should continue to do so.
>
> Mhmm, I disagree.  I think that FreeType should provide a single, most
> basic solution for convenience – it's really just a few lines of code.
> This is also a wish from
>
>   https://savannah.nongnu.org/bugs/?44689#comment22
>
> I'm no expert in blending, so please help improve the code!  It should
> do the right thing in a clean way, not necessarily as fast as
> possible.

Lets do it properly then. Let's blend a layer or a glyph (in color)
onto an arbitrary background image with gamma correction. I just
checked that finite difference approximation for gamma ramps works
pretty good.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] commit #84eebf4802 breaks compilation with older version of MSVC

[John Emmas]

On 17/05/2018 18:41, Werner LEMBERG wrote:

However, MSVC-8 seems happy with this underscored variant, if that
helps...

 static __inline FT_Int32

Fixed in git, thanks.



Thanks Werner - another heads-up though...

Fixing that issue has simply highlighted another problem five lines 
later, namely:-


  _BitScanReverse ( %where, x );

Bear in mind that Visual Studio didn't introduce _BitScanReverse until 
VS2013 (MSDN says VS2010 but I think that's wrong).  Either way, the 
above change has made freetype2 unbuildable now with anything earlier  :-(


John

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel