Re: [Podofo-users] TTC font related issues in Windows

[Jaseem A. K T <jas...@hc...>]

Hi

Thanks for the reply

I did some tests. I have a system with Japanese language. I set the system locale to Russian , Arabic etc and tested the code. I was able to get Meiryo font. I tested other fonts too and I was able to get others also.

We do , after all ,depend on windows API, to get the font file buffer. If we can trust the API to give the correct file buffer(for the font), I think we can trust the same API(we are using the same function) in helping us to extract the correct font also.(The only problem is it is closed source, and we would not be able to debug. We'd just have to trust them. But , since the code is already running on windows we are already 'trusting' them many places)

The pre-patch code didn't have fontstyle matching. Introducing this to pre-patch code, may require, that we have to take care of font style names in each language, locale etc. And we are not sure what other things we are going to miss.
.......

May be a more refined approach would be pass the correct face index to freetype library (In place of the logic for extracting the font by adjusting offsets) . (Side Note: what I understand by reading podofo code is that, in non-windows systems, the fontmanager will give the path of the required font, and this is passed to freetype library as FT_New_Face( *pLibrary, pszFilename, 0, &m_pFace );
Here the face index is always zero. Which means we always load the first font of the ttc file, which may not be what we wanted. )
..........


Regards
Ali

From: dennis [mailto:den...@do...]
Sent: Monday, August 22, 2016 12:38 PM
To: pod...@li...
Subject: Re: [Podofo-users] TTC font related issues in Windows

Hey there,

I was on vacation so i didnt read emails :-)

Regarding the patch:
Looks good, according to msdn this should work fine...
I dont really like the use of the Windows API and i am unable to test this patch atm due to time limitations (can you believe it? I have to do work at my workplace ;-) ).
The code looks fine, if Jaseem has tested it, it should be ok.

Why do i not like the Windows api approach?
First of all :
The pre-patch code did all kinds of locale checks, encoding checks etc. this needs to be done if working with ttc/ttfs.
This seems to be all hidden in the windows api call... if this code does not work the way we want it to work it will be very hard to find the actually error...

Second:
I dont trust Micro$ofts Apis. They are janky and have all sorts of traps in them...

What i would like to see is:
This Patch on a Japanese System with Russian Languange pack installed asking for Meiryo. If Podofo handles this case it should be good for every case...
(Doesnt have to be japanese and russian, but it should be 2 different languages which both have a non latin alphabet)

BUT, that said:
The api approach is less codelines and you need almost no knowledge about the ttc/ttf format to understand the code so thats a big plus!

Greetings,
Dennis


--

[dots]<http://www.dots.de/en/>

Dennis Voss

dots Software GmbH
Schlesische Str. 27, 10997 Berlin, Germany

Tel: +49 (0)30 695 799-47
Fax: +49 (0)30 695 799-55

den...@do...<mailto:den...@do...>
http://www.dots.de<http://www.dots.de/>

Amtsgericht Berlin Charlottenburg HRB 65201
Geschäftsführer: Olaf Lorenz
Follow us on:

[Twitter]<http://www.dots.de/?id=twitter>

[Youtube]<http://www.dots.de/?id=youtube>

[Xing]<http://www.dots.de/?id=xing>





::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------