[bug#53536] [PATCH 0/1] Add poppler-with-data.

[Liliana Marie Prikler]

Hi,

Am Mittwoch, dem 26.01.2022 um 22:38 +0900 schrieb Taiju HIGASHI:
> > Instead, I suggest we make poppler-with-data a replacement for
> > poppler, which should by package/inherit then also apply to the
> > other variants.
> > 
> > I've CC'd Marius, Tobias and Leo to aid me in my judgement here,
> > but I think grafts would be necessary if we don't want to do input
> > rewriting with several variants.
> 
> I apologize if I didn't understand exactly what you meant.
> Am I correct in understanding that the direction of this patch is
> correct?
> 
> The idea is to create a variant called poppler-qt5-with-data and
> replace the input of packages that depend on poppler-qt5 with it.
> 
> I'm starting to think that this patch proposal is a realistic and
> reasonable solution.
I think we can agree that the patch moves in the right direction, but
I'm not sure whether we can claim to be "there yet" with just that
patch alone.  If we want to make it so that evince handles CJK out of
the box (without the user needing to rewrite inputs), we would have to
replace poppler with poppler-with-data. On master first by grafts, and
on core-updates by adding it as input directly.

> I'm using poppler-with-data to write the manifest, but without
> poppler-with-data, I'm not sure what I'd do.
> 
> In fact, I'm using poppler-with-data to write manifests, and it's
> much better than not using poppler-with-data.
> 
> At least I don't have to redefine evince etc. on my own anymore.
> 
> ref:
> https://git.sr.ht/~taiju/taix/tree/8a3ab4407eefe720193e401cf8f11d96550733e9/item/guix-config/package-config.scm
> 
> 
> If I am interpreting your reply incorrectly, I would appreciate it if
> you could be more specific.
What works for you in a manifest is not necessarily something that
should be pushed to upstream as-is.  As you can easily see, it's a
transformation you're able to do locally regardless of the state of the
Guix repo.  For the main channel, "quick hacks to alleviate problems"
are typically discouraged in favour of varying degrees of "proper
solutions".

> > Are there any other packages you might want to install into
> > POPPLER_INSTALL_PREFIX?  If so, a colon-separated POPPLER_DATA_PATH
> > should be preferred.  Note that if we add that feature, we'd still
> > have to graft it on master currently.
> 
> At the moment, there is nothing other than poppler-data that we want
> to install in POPPLER_INSTALL_PREFIX.
> 
> However, this idea, while generic, may be confusing to users, as
> shown in the reason why it was deprecated in Nix.
> At least, if the package poppler-with-data exists, we can speculate
> that it might be able to solve the problem.
> 
> QUOTE:
>     Previously we relied on an environment variable POPPLER_DATADIR
>     which practically noone used and everyone was expected to set.  
> This is a good candidate for a feature option because noone
>     really _noticed_ that this data is not available.  Disabled by
>     default because of this and size of the data (22M).

Unlike Nix, we don't have feature options (not until Ludo pushes the
code to add them, at least, but that too appears to be at least one
core-updates cycle away), so it's either the all-or-nothing approach of
having or not having it as input to poppler, or the environment
variable.  Looking at the output of `guix size', poppler takes up 138.1
MiB on a disk with 7.3 MiB being poppler itself, whereas poppler-data
takes up 12.4 MiB.  I personally think that tradeoff to be worth it --
as in "let's include poppler-data in poppler so as to not discriminate
against our Non-Latin script users".  It's an increase of less than 10%
to support clearly more than 10% of the world's population (though how
many of them use PDFs is an uncertain number).

Cheers