No subject

[Shivodit Gill]

Hello,

Sorry about the ambiguous wording, what I meant to say was - after
obtaining the correct font, how does the font API for desktop Poppler
send the font for rendering to the correct backend (Cairo/Splash)?

In short, I'm trying to understand the implementation of the current
font API on desktop Poppler. This is to get an idea of how the Android
font API based on FontMatcher would be designed - how it would get
details of fonts that are unembedded in the pdf, and other such things.

After looking through the Poppler repo, I think poppler/GfxFont.h and
poppler/GfxFont.cc are the files which contain the implementation of the
desktop font API. If I'm mistaken or if there are more files which
provide the desktop font API, please point it out.

Thanks,
Shivodit


On 3/20/23 03:31, Albert Astals Cid wrote:
> El dissabte, 18 de març de 2023, a les 22:27:38 (CET), Shivodit Gill va 
> escriure:
>> 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?
> 
> Who is we? There's nothing that needs to be passed to poppler, the change  
> needs to happen in poppler as mentioned in the gsoc description.
> 
> Cheers,
>   Albert
> 
>>
>> 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?us
>>>> p=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
> 
> 
> 
>