Usage with Freetype, wrong values returned

[Jorn Vernee]

P.S. FWIW, jextract should generate an FT_CharMap layout in freetype_h 
as well that you could use instead of POINTER:

         // Let's now iterate over the structs and print the encoding 
(which is problematic)
         MemorySegment arrPointer = FT_FaceRec.charmaps$get(faceMemory);
         arrPointer
             .reinterpret(FT_CharMap.byteSize() * num) // it's an array 
of FT_CharMap
             .elements(FT_CharMap) // the elements are FT_CharMaps
             .map(s -> s.get(FT_CharMap, 0)) // 's' is a slice of the 
array. Get an FT_CharMapfrom the array
             .forEach(Test::printCharMap);

Jorn

On 13/11/2023 11:59, Jorn Vernee wrote:
>
> Hey Alessandro,
>
> I think there is a bug in this section of your code:
>
>         // Let's now iterate over the structs and print the encoding 
> (which is problematic)
>         MemorySegment arrPointer = FT_FaceRec.charmaps$get(faceMemory);
>         arrPointer.get(POINTER, 0)
>             .reinterpret(FT_CharMapRec_.$LAYOUT().byteSize() * num)
>             .elements(FT_CharMapRec_.$LAYOUT())
>             .forEach(Test::printCharMap);
>
> Looking at the documentation: [1], [2]. The 'charmaps' field of a face 
> is an array of _pointers_ to FT_CharMapRec_ (note that FT_CharMap is a 
> pointer to a FT_CharMapRec_), not an array of FT_CharMapRec_. Your 
> code, however, is getting the pointer to the first struct from the 
> array, and then reinterpreting that pointer as an array of structs, 
> while it's actually just a pointer to a single FT_CharMapRec_ struct 
> (not an array). That explains why the first element looks valid, but 
> the second doesn't.
>
> Treating the array as an array of pointers instead, I think this 
> should work:
>
>         // Let's now iterate over the structs and print the encoding 
> (which is problematic)
>         MemorySegment arrPointer = FT_FaceRec.charmaps$get(faceMemory);
>         arrPointer
>             .reinterpret(POINTER.byteSize() * num) // it's an array of 
> pointers
>             .elements(POINTER) // the elements are pointers
>             .map(s -> s.get(POINTER, 0)) // 's' is a slice of the 
> array. Get a pointer to a struct from the array
>             .forEach(Test::printCharMap);
>
> HTH,
> Jorn
>
> [1]: 
> https://freetype.org/freetype2/docs/reference/ft2-face_creation.html#ft_facerec
> [2]: 
> https://freetype.org/freetype2/docs/reference/ft2-character_mapping.html#ft_charmap
>
> On 13/11/2023 11:11, Alessandro Parisi wrote:
>> Hello everyone,
>> In the recent weeks, I've been experimenting with Project Panama on 
>> JDK 21. I'm trying to create a wrapper for the Freetype font library 
>> written in C, but I'm having some issues, probably because I still 
>> don't understand very well the FFM API.
>> While using the code generated by JExtract, I noticed that it fails 
>> to parse the /charmaps/ array from the FT_FaceRec 
>> <https://freetype.org/freetype2/docs/reference/ft2-face_creation.html#ft_facerec> struct. 
>> With the TTF font, I'm testing, there are two /charmaps/, the values 
>> of the first one are the same printed by the native code too, but for 
>> the second, the values are completely randomic
>> Here is a little reproducer: FreetypeMRE 
>> <https://www.dropbox.com/scl/fi/gitugnyxe3kyomm4m0pke/FreetypeMRE.zip?rlkey=tvnrsb5ernwasmxj6cgrjyqqq&dl=0>
>> Running the Test class will print the two /charmaps/. There is also a 
>> little .exe I built to check the output of native code, it's located 
>> in the src/native directory (there is also the C src code)
>> Am I doing something wrong, or is this a bug?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20231113/abbfcf3c/attachment-0001.htm>