No subject

[Shivodit Gill]

Hello,

Thanks for clearing that up!

Also, while I was writing my proposal, I started wondering - how do we
pass the font object to Poppler so it can use it?

AFontMatcher can take a string of text, and return the best matching
font as a pointer to an AFont object.

How will this AFont object be used to render the text in Poppler?

I tried doing some research of my own in the Poppler repository but
ended up getting confused. I couldn't find any documentation for how to
render some text with a given font in Poppler. I couldn't find much info
about the AFont datatype either.

Using the AFont object, we can find the path of the returned font, which
can be used to open said font file in O_RDONLY mode. Maybe we can pass
that to Poppler?

Thanks,
Shivodit


On 3/16/23 04:35, Albert Astals Cid wrote:
> El dimecres, 15 de març de 2023, a les 22:23:19 (CET), Shivodit Gill va 
> escriure:
>> On 3/15/23 05:07, Albert Astals Cid wrote:
>>> El dimarts, 14 de març de 2023, a les 22:30:38 (CET), Shivodit va 
> escriure:
>>>> Hello,
>>>
>>> Hello, please write a Subject to your emails.
>>
>> Sorry about that, I forgot to add a subject line and only realized it
>> after I had sent the mail, since GMail doesn't warn about missing
>> subject lines. I'll make sure to not repeat this in the future.
>>
>>>> I am a college student planning to contribute to KDE for GSoC '23, by
>>>> taking on the task of improving Okular on Android. I have the following
>>>> questions:
>>>>
>>>> 1.  What will be the use case of implementing the Android AFontMatcher
>>>>
>>>>     font API?
>>>>     
>>>>     Initially I had tested a .pdf file in Okular for Android, and the
>>>>     text in that file did not load at all. So I assumed that this API
>>>>     would help to find the correct fonts in such situations, so that
>>>>     text content could be properly shown.
>>>
>>> Exactly.
>>>
>>>>     However, now I am not sure - I tried some other pdfs with text,
>>>>     and all of them rendered the text correctly. The issue with font
>>>>     rendering only occurs when viewing the earlier mentioned pdf file.
>>>>     If I use the "Print to file" option to create a duplicate of the
>>>>     problematic pdf, the duplicated pdf loads correctly on Okular for
>>>>     Android. Weirdly enough, the same problematic pdf renders correctly
>>>>     when opened in desktop Okular.
>>>>
>>>> 2.  Since the AFontMatcher API will be implemented in the Poppler
>>>> backend,
>>>>
>>>>     I was wondering in which files/directories the programming work
>>>>     would be done.
>>>>     
>>>>     Initially I assumed work would be done in the generator/poppler
>>>>     directory of the Okular repo, but that turned out to be incorrect.
>>>>     
>>>>     After some digging, I stumbled upon the freedesktop Poppler repo,
>>>>     (https://gitlab.freedesktop.org/poppler/poppler and it contains)
>>>>     the code files for the Qt5 Poppler interface. I'm guessing the work
>>>>     will be done here?
>>>
>>> No, the code will not be in the Qt5 Poppler interface, keep digging your
>>> almost there.
>>
>> I see, me being close probably means I'm in the correct repo, right? If
>> yes, then my guess is that the work will be happening in the poppler
>> directory of the Poppler repo. Reasoning being that it contains some
>> .cc/.cpp files which deal with some information related to fonts..
> 
> Yes, that is the proper folder.
> 
>>
>>>> 3.  This is a bit off-topic, but why is the pdf mentioned above having
>>>>
>>>>     trouble with text rendering? All other pdfs with text content render
>>>>     correctly, but only this specific file has trouble with loading on
>>>>     Android Okular but it gets shown correctly everywhere else, including
>>>>     other pdf viewers on Android. I can send the pdf if someone
>>>>     would like to take a look at it.
>>>
>>> Without the PDF I can only guess is because the PDF doesn't embed its
>>> fonts.
>> I see, so maybe duplicating the entire pdf using the 'Print to File'
>> functionality causes the proper fonts/their substitutes to get embedded?
>>
>> I've also uploaded the faulty pdf I mentioned to this google drive link,
>> please check it out when you get the chance.
>>
>> Faulty pdf:
>> https://drive.google.com/file/d/1oid-cZwady9jaCpdZb4wShflDId-RHFu/view?usp=s
>> haring
> 
> There's nothing faulty about that pdf, having non embedded fonts is perfectly 
> ok, and that's why we need poppler+Android to support that scenario.
> 
> Cheers,
>   Albert
> 
>>
>> Thanks,
>> Shivodit
>>
>>> Cheers,
>>>
>>>   Albert
>>>>
>>>> Thanks,
>>>> Shivodit
> 
> 
> 
>