No subject

[Albert Astals Cid]

El dilluns, 20 de març de 2023, a les 21:56:13 (CEST), Shivodit Gill va 
escriure:
> 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.

You want to look at GlobalParams.

Cheers,
  Albert

> 
> 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