Re: Usage of okular on windows

[Albert Astals Cid]

El dijous, 14 de març de 2024, a les 20:17:44 (CET), Lionel Bruno va escriure:
> Dear Okular developers,
> 
> We are a french institution that adopted Okular on our computers ( tired of
> Acrobat advertising in their GUI ).
> 
> We used to download the windows version from binary-factory.kde.org  ( the
> windows store is not allowed on our machines ).

The replacement for unstable releases is 
https://cdn.kde.org/ci-builds/graphics/okular/master/
but we don't have windows build yet.

> 
> Is there an alternative way to get the recent version and future updates
> outside the windows store ?

For the official build you can always download it from download.kde.org i.e.
https://download.kde.org/Attic/release-service/23.08.1/windows/

But it's a bit tricky because you have to know which of the releases had a 
windows release.

> 
> Thanks for your great work and thanks in advance you for your response.

We do not provide an auto-updater besides Windows Store.

choco seems to have okular
https://community.chocolatey.org/packages/okular
But i have no idea how much you can trust those packages or if choco would be 
allowed on your computers.

Cheers,
  Albert

> 
> 
> regards
> 
> ---
> Lionel Bruno
> 
> Service des systèmes d'information
> +33 1 47 03 89 12
> lionel.br...@inha.fr

[okular] [Bug 353389] REQUEST: Obvious overlap position indicator to prevent re-reading overlap

[El Oton]

https://bugs.kde.org/show_bug.cgi?id=353389

--- Comment #2 from El Oton  ---
When I made this request 9 years ago, it was at the bottom of the "General"
settings tab.  I'm not presently using KDE so I don't know.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 353389] REQUEST: Obvious overlap position indicator to prevent re-reading overlap

[Joe Breuer]

https://bugs.kde.org/show_bug.cgi?id=353389

Joe Breuer  changed:

   What|Removed |Added

 CC||k...@jmbreuer.net

--- Comment #1 from Joe Breuer  ---
What... overlap? Did you turn that on at some place? (Where?)

I came here with the feature request to have (some, ideally configurable)
overlap when using PgUp/PgDn in Continuous Mode. In the PDF document I'm
currently reading, Okular will skip by _exactly_ the whole page, even when that
means splitting a line of text in half. ...

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Question for OKULAR stamps

[Albert Astals Cid]

El diumenge, 18 de febrer de 2024, a les 10:24:05 (CET), Alain LAPIERE va 
escriure:
> Hello
> 2 questions

In the future please use https://kde.org/support/ to find support channels, do 
not email the Okular development mailing list about how to use Okular.

> How resize a stamp when it is put on a pdf ?

Be in Browse mode, select the stamp with the mouse, drag the square markers 
that appear around the stamp.

> Hox resize a stamp when we create it ?

When adding the stamp (and most annotations) press the mouse button, hold and 
drag to the size of the stamp you want to create, then release the mouse 
button.

Cheers,
  Albert

> Best regards

Re: Removing plucker generator ?

[Albert Astals Cid]

El dijous, 25 de gener de 2024, a les 0:33:58 (CET), Albert Astals Cid va 
escriure:
> El dimecres, 17 de gener de 2024, a les 13:45:03 (CET), Sune Stolborg
> Vuorela
> va escriure:
> > Hi
> > 
> > While doing changes for KF6, I also touched the plucker generator code a
> > bit. And I'm not confident in the code.
> > 
> > It's c-code originating in 2003.
> > It seems to be trusting the input is good.
> > I found potential crasher bugs in it by looking at it
> > It has no tests
> > It doesn't look like the code has met some fuzzy-tester
> > 
> > If it requires a owner key, it needs to be provided in a configuration
> > file
> > somewhere on disk, and trying that ends up with out of bounds writes and
> > crashes. The configuration file it tries to open is btw called:
> > PLUCKER_CONFIG_DIRFILE_SEPARATOR_CHAR_SSYS_CONFIG_FILE_NAME
> > (and stored in a char* malloc'ed to be 40 chars long).
> > 
> > It has foo = realloc(foo,...); foo[n].bar = ...; Realloc returns null on
> > failure.
> > 
> > It's hard to find test data for it. Any data.
> > The homepage of the format seems to have been repurposed many years ago to
> > something else.
> > 
> > I think we should either find someone to take ownership over this and
> > promise to invest a significant amount of time into it. Or just remove it.
> 
> CC'in Tobias (if that address still works) in case he has some input.
> 
> I've never seen any plucker document myself.

No answer from anyone so this was actioned.

https://invent.kde.org/graphics/okular/-/merge_requests/921

Cheers,
  Albert

> 
> Cheers,
>   Albert
> 
> > /Sune

Re: KEcoLab's integration into Okular

[Aakarsh MJ]

Hi Albert,

Once again sorry for the delay in response me and karan were attending Conf
KDE India so were a bit preoccupied with that

>Try following the steps, you will see that you can't do step 1 because
that is
>not something we have in KDE (I guess one could bother sysadmin about it,
but
>that's not scalable).

Yes you are correct we'll have to ask sysadmins for this. For this we would
create a template to make this easy to achieve where we can have a comma
seperated list of email addresses to notify when the pipeline breaks.
Although this would be the last step for integration

In regards to concern around scalability at present we were only looking to
work with select projects owing to limited availability of hardware and
also bearing in mind measuring too many projects can overload the system
under test.

Also on 14 February we would be having our monthly KDE Eco meetup and from
what I have been told joseph will contact you in regards to this so maybe
we can go into more details over this which would help in a smoother
conversation.

Sincerely,
Aakarsh MJ

On Thu, Feb 1, 2024 at 3:18 AM Albert Astals Cid  wrote:

> El dimecres, 31 de gener de 2024, a les 4:48:04 (CET), DrQuark va escriure:
> > Hi Albert,
> > I am Karanjot Singh, one of the developers from the KEcolab Team.
> >
> >
> > You can configure a list of people that would receive an email when the
> > pipeline status changes.
> > See
> https://docs.gitlab.com/ee/user/project/integrations/pipeline_status_em
> > ails.html
>
> Try following the steps, you will see that you can't do step 1 because
> that is
> not something we have in KDE (I guess one could bother sysadmin about it,
> but
> that's not scalable).
>
> Cheers,
>   Albert
>
> >
> >
> > Cheers,
> > Karanjot
> >
> >
> >
> >
> >
> > On Wed, Jan 31, 2024 at 04:39, Albert Astals Cid  wrote:
> >
> > El dilluns, 29 de gener de 2024, a les 20:11:20 (CET), Aakarsh MJ va
> escriure:
> > > Sorry for the late reply,
> > >
> > > > > Please remember to keep the list in copy :)
> > >
> > > My mistake, I made sure to include all in this reply
> > >
> > > > Doing the testing on the tag creation may be a bit too late since we
> > > > only
> > > >
> > > > create the tag when the application is released, which means if the
> test
> > > > finds
> > > >
> > > > a regression, it's too late since we've already released.
> > > >
> > > >
> > > > But I guess as a start is not a bad thing, at least we'd know a
> > > > regression
> > > >
> > > > happened :D
> > >
> > > Great!
> > >
> > > > Speaking of which, how would we know a regression happened? I
> understand
> > > > the
> > > >
> > > > pipeline would fail, but since "noone" is specifically looking at
> that
> > > >
> > > > pipeline it would possibly be "lost"? Maybe we can get an email on
> the
> > > > mailing
> > > >
> > > > list? But I guess that's step #2.
> > >
> > > Yes, iirc whenever a pipeline fails the maintainers do receive an email
> >
> > > similar to the following image:
> > Are you sure this is how it works?
> >
> > For Okular I only get emails when I break it, not when someone else does.
> >
> > Cheers,
> > Albert
> >
> > > [image: image.png]
> > > and even if the deploy stage fails we would still have artefacts from
> the
> > > energy measurement stage.
> > >
> > > Sincerely,
> > > Aakarsh MJ
> > >
> > > On Fri, Jan 26, 2024 at 4:32 AM Albert Astals Cid 
> wrote:
> > > > El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va
> > > >
> > > > escriure:
> > > > > Hi Albert,
> > > >
> > > > Please remember to keep the list in copy :)
> > > >
> > > > > So we are planning to integrate this in the gitlab pipeline and are
> > > >
> > > > looking
> > > >
> > > > > to leverage `release-tags` (eg tag v 1.0) to identify the release
> > > > > KEcoLab
> > > > > runner would automatically run on and additionally the measurement
> > > >
> > > > process
> > > >
> > > > > can also be run manually at any time.
> > > >
> > > > Doing the testing on the tag creation may be a bit too late since we
> > > > only
> > > > create the tag when the application is released, which means if the
> test
> > > > finds
> > > > a regression, it's too late since we've already released.
> > > >
> > > > But I guess as a start is not a bad thing, at least we'd know a
> > > > regression
> > > > happened :D
> > > >
> > > > Speaking of which, how would we know a regression happened? I
> understand
> > > > the
> > > > pipeline would fail, but since "noone" is specifically looking at
> that
> > > > pipeline it would possibly be "lost"? Maybe we can get an email on
> the
> > > > mailing
> > > > list? But I guess that's step #2.
> > > >
> > > > Cheers,
> > > >
> > > > Albert
> > > >
> > > > > Sincerely,
> > > > > Aakarsh MJ
> > > > >
> > > > > On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid 
> wrote:
> > > > > > El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ
> va
> > > > > >
> > > > > > escriure:
> > > > > > > request "reply all"
> > > > > > >
> > > > > > 

Re: KEcoLab's integration into Okular

[DrQuark]

<<< text/html; charset=utf-8: Unrecognized >>>


publicKey - thestrangequarks@protonmail.com - 0xA1F859C9.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: KEcoLab's integration into Okular

[Albert Astals Cid]

El dimecres, 31 de gener de 2024, a les 4:48:04 (CET), DrQuark va escriure:
> Hi Albert,
> I am Karanjot Singh, one of the developers from the KEcolab Team. 
> 
> 
> You can configure a list of people that would receive an email when the
> pipeline status changes. 
> See https://docs.gitlab.com/ee/user/project/integrations/pipeline_status_em
> ails.html

Try following the steps, you will see that you can't do step 1 because that is 
not something we have in KDE (I guess one could bother sysadmin about it, but 
that's not scalable).

Cheers,
  Albert

> 
> 
> Cheers,
> Karanjot
> 
> 
> 
> 
> 
> On Wed, Jan 31, 2024 at 04:39, Albert Astals Cid  wrote:
> 
> El dilluns, 29 de gener de 2024, a les 20:11:20 (CET), Aakarsh MJ va 
escriure:
> > Sorry for the late reply,
> > 
> > > > Please remember to keep the list in copy :)
> > 
> > My mistake, I made sure to include all in this reply
> > 
> > > Doing the testing on the tag creation may be a bit too late since we
> > > only
> > > 
> > > create the tag when the application is released, which means if the test
> > > finds
> > > 
> > > a regression, it's too late since we've already released.
> > > 
> > > 
> > > But I guess as a start is not a bad thing, at least we'd know a
> > > regression
> > > 
> > > happened :D
> > 
> > Great!
> > 
> > > Speaking of which, how would we know a regression happened? I understand
> > > the
> > > 
> > > pipeline would fail, but since "noone" is specifically looking at that
> > > 
> > > pipeline it would possibly be "lost"? Maybe we can get an email on the
> > > mailing
> > > 
> > > list? But I guess that's step #2.
> > 
> > Yes, iirc whenever a pipeline fails the maintainers do receive an email
> 
> > similar to the following image:
> Are you sure this is how it works?
> 
> For Okular I only get emails when I break it, not when someone else does.
> 
> Cheers,
> Albert
> 
> > [image: image.png]
> > and even if the deploy stage fails we would still have artefacts from the
> > energy measurement stage.
> > 
> > Sincerely,
> > Aakarsh MJ
> > 
> > On Fri, Jan 26, 2024 at 4:32 AM Albert Astals Cid  wrote:
> > > El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va
> > > 
> > > escriure:
> > > > Hi Albert,
> > > 
> > > Please remember to keep the list in copy :)
> > > 
> > > > So we are planning to integrate this in the gitlab pipeline and are
> > > 
> > > looking
> > > 
> > > > to leverage `release-tags` (eg tag v 1.0) to identify the release
> > > > KEcoLab
> > > > runner would automatically run on and additionally the measurement
> > > 
> > > process
> > > 
> > > > can also be run manually at any time.
> > > 
> > > Doing the testing on the tag creation may be a bit too late since we
> > > only
> > > create the tag when the application is released, which means if the test
> > > finds
> > > a regression, it's too late since we've already released.
> > > 
> > > But I guess as a start is not a bad thing, at least we'd know a
> > > regression
> > > happened :D
> > > 
> > > Speaking of which, how would we know a regression happened? I understand
> > > the
> > > pipeline would fail, but since "noone" is specifically looking at that
> > > pipeline it would possibly be "lost"? Maybe we can get an email on the
> > > mailing
> > > list? But I guess that's step #2.
> > > 
> > > Cheers,
> > > 
> > > Albert
> > > 
> > > > Sincerely,
> > > > Aakarsh MJ
> > > > 
> > > > On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid  
wrote:
> > > > > El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ va
> > > > > 
> > > > > escriure:
> > > > > > request "reply all"
> > > > > > 
> > > > > > Hello everyone, My name is Aakarsh MJ, I’m contacting you on
> > > > > > behalf
> > > 
> > > of
> > > 
> > > > > the
> > > > > 
> > > > > > KDE Eco’s KEcoLab team for proposing the integration of KEcoLab
> > > > > > into
> > > > > > Okular’s pipeline. There are 2 proposed models (you can also
> > > > > > suggest
> > > > > > your
> > > > > > own) which are as follows:
> > > > > > 
> > > > > > 1) Pre-release Testing:
> > > > > > * Every release candidate would be tested for energy consumption.
> > > > > > * Provide information about energy change with the previous
> > > > > > versions
> > > 
> > > to
> > > 
> > > > > > maintain the Blue Angel’s recommended less than 10% increase from
> > > > > > the
> > > > > 
> > > > > time
> > > > > 
> > > > > > of certification requirement.
> > > > > > 
> > > > > > 2) Optional Merge Request Testing (MRT)
> > > > > > * Maintainers can opt to run KEcoLab on specific merge requests
> > > 
> > > based on
> > > 
> > > > > > their potential impact on energy consumption.
> > > > > > * Smaller changes or bug fixes may not require MRT, while large
> > > 
> > > feature
> > > 
> > > > > > additions could benefit from energy analysis
> > > > > > * This approach allows for targeted testing, while at the same
> > > > > > time
> > > > > > ensuring we are not consuming unnecessary energy.
> > > > > > 
> > > > > > If approved me and 

Re: KEcoLab's integration into Okular

[Albert Astals Cid]

El dilluns, 29 de gener de 2024, a les 20:11:20 (CET), Aakarsh MJ va escriure:
> Sorry for the late reply,
> 
> > > Please remember to keep the list in copy :)
> 
> My mistake, I made sure to include all in this reply
> 
> > Doing the testing on the tag creation may be a bit too late since we only
> > 
> > create the tag when the application is released, which means if the test
> > finds
> > 
> > a regression, it's too late since we've already released.
> > 
> > 
> > But I guess as a start is not a bad thing, at least we'd know a
> > regression
> > 
> > happened :D
> 
> Great!
> 
> > Speaking of which, how would we know a regression happened? I understand
> > the
> > 
> > pipeline would fail, but since "noone" is specifically looking at that
> > 
> > pipeline it would possibly be "lost"? Maybe we can get an email on the
> > mailing
> > 
> > list? But I guess that's step #2.
> 
> Yes, iirc whenever a pipeline fails the maintainers do receive an email
> similar to the following image:

Are you sure this is how it works?

For Okular I only get emails when I break it, not when someone else does.

Cheers,
  Albert

> [image: image.png]
> and even if the deploy stage fails we would still have artefacts from the
> energy measurement stage.
> 
> Sincerely,
> Aakarsh MJ
> 
> On Fri, Jan 26, 2024 at 4:32 AM Albert Astals Cid  wrote:
> > El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va
> > 
> > escriure:
> > > Hi Albert,
> > 
> > Please remember to keep the list in copy :)
> > 
> > > So we are planning to integrate this in the gitlab pipeline and are
> > 
> > looking
> > 
> > > to leverage `release-tags` (eg tag v 1.0) to identify the release
> > > KEcoLab
> > > runner would automatically run on and additionally the measurement
> > 
> > process
> > 
> > > can also be run manually at any time.
> > 
> > Doing the testing on the tag creation may be a bit too late since we only
> > create the tag when the application is released, which means if the test
> > finds
> > a regression, it's too late since we've already released.
> > 
> > But I guess as a start is not a bad thing, at least we'd know a regression
> > happened :D
> > 
> > Speaking of which, how would we know a regression happened? I understand
> > the
> > pipeline would fail, but since "noone" is specifically looking at that
> > pipeline it would possibly be "lost"? Maybe we can get an email on the
> > mailing
> > list? But I guess that's step #2.
> > 
> > Cheers,
> > 
> >   Albert
> >   
> > > Sincerely,
> > > Aakarsh MJ
> > > 
> > > On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid  wrote:
> > > > El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ va
> > > > 
> > > > escriure:
> > > > > request "reply all"
> > > > > 
> > > > > Hello everyone, My name is Aakarsh MJ, I’m contacting you on behalf
> > 
> > of
> > 
> > > > the
> > > > 
> > > > > KDE Eco’s KEcoLab team for proposing the integration of KEcoLab into
> > > > > Okular’s pipeline. There are 2 proposed models (you can also suggest
> > > > > your
> > > > > own) which are as follows:
> > > > > 
> > > > > 1) Pre-release Testing:
> > > > > * Every release candidate would be tested for energy consumption.
> > > > > * Provide information about energy change with the previous versions
> > 
> > to
> > 
> > > > > maintain the Blue Angel’s recommended less than 10% increase from
> > > > > the
> > > > 
> > > > time
> > > > 
> > > > > of certification requirement.
> > > > > 
> > > > > 2) Optional Merge Request Testing (MRT)
> > > > > * Maintainers can opt to run KEcoLab on specific merge requests
> > 
> > based on
> > 
> > > > > their potential impact on energy consumption.
> > > > > * Smaller changes or bug fixes may not require MRT, while large
> > 
> > feature
> > 
> > > > > additions could benefit from energy analysis
> > > > > * This approach allows for targeted testing, while at the same time
> > > > > ensuring we are not consuming unnecessary energy.
> > > > > 
> > > > > If approved me and sarthak negi will be working on it as part of KDE
> > 
> > SoK
> > 
> > > > > 24. You can also check my proposal(
> > > > > https://invent.kde.org/teams/season-of-kde/2024/-/issues/24) and
> > > > 
> > > > sarthak's
> > > > 
> > > > > proposal(https://invent.kde.org/teams/season-of-kde/2024/-/issues/19
> > 
> > )
> > 
> > > > > I am eager to hear your feedback, answer any questions and discuss
> > 
> > the
> > 
> > > > most
> > > > 
> > > > > effective implementation approach. Thanks for your time and
> > > > 
> > > > consideration.
> > > > 
> > > > Would this be a gitlab thing or be in a separate service?
> > > > 
> > > > How would you implement 1) i.e. how do you know what/when a
> > 
> > "pre-release"
> > 
> > > > exactly is?
> > > > 
> > > > Cheers,
> > > > 
> > > >   Albert

Re: KEcoLab's integration into Okular

[Aakarsh MJ]

Sorry for the late reply,



> > Please remember to keep the list in copy :)
>

My mistake, I made sure to include all in this reply

> Doing the testing on the tag creation may be a bit too late since we only

> create the tag when the application is released, which means if the test
> finds

> a regression, it's too late since we've already released.


> But I guess as a start is not a bad thing, at least we'd know a
> regression

> happened :D
>

Great!

> Speaking of which, how would we know a regression happened? I understand
> the

> pipeline would fail, but since "noone" is specifically looking at that

> pipeline it would possibly be "lost"? Maybe we can get an email on the
> mailing

> list? But I guess that's step #2.


Yes, iirc whenever a pipeline fails the maintainers do receive an email
similar to the following image:
[image: image.png]
and even if the deploy stage fails we would still have artefacts from the
energy measurement stage.

Sincerely,
Aakarsh MJ

On Fri, Jan 26, 2024 at 4:32 AM Albert Astals Cid  wrote:

> El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va
> escriure:
> > Hi Albert,
>
> Please remember to keep the list in copy :)
>
> > So we are planning to integrate this in the gitlab pipeline and are
> looking
> > to leverage `release-tags` (eg tag v 1.0) to identify the release KEcoLab
> > runner would automatically run on and additionally the measurement
> process
> > can also be run manually at any time.
>
> Doing the testing on the tag creation may be a bit too late since we only
> create the tag when the application is released, which means if the test
> finds
> a regression, it's too late since we've already released.
>
> But I guess as a start is not a bad thing, at least we'd know a regression
> happened :D
>
> Speaking of which, how would we know a regression happened? I understand
> the
> pipeline would fail, but since "noone" is specifically looking at that
> pipeline it would possibly be "lost"? Maybe we can get an email on the
> mailing
> list? But I guess that's step #2.
>
> Cheers,
>   Albert
>
> >
> > Sincerely,
> > Aakarsh MJ
> >
> > On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid  wrote:
> > > El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ va
> > >
> > > escriure:
> > > > request "reply all"
> > > >
> > > > Hello everyone, My name is Aakarsh MJ, I’m contacting you on behalf
> of
> > >
> > > the
> > >
> > > > KDE Eco’s KEcoLab team for proposing the integration of KEcoLab into
> > > > Okular’s pipeline. There are 2 proposed models (you can also suggest
> > > > your
> > > > own) which are as follows:
> > > >
> > > > 1) Pre-release Testing:
> > > > * Every release candidate would be tested for energy consumption.
> > > > * Provide information about energy change with the previous versions
> to
> > > > maintain the Blue Angel’s recommended less than 10% increase from the
> > >
> > > time
> > >
> > > > of certification requirement.
> > > >
> > > > 2) Optional Merge Request Testing (MRT)
> > > > * Maintainers can opt to run KEcoLab on specific merge requests
> based on
> > > > their potential impact on energy consumption.
> > > > * Smaller changes or bug fixes may not require MRT, while large
> feature
> > > > additions could benefit from energy analysis
> > > > * This approach allows for targeted testing, while at the same time
> > > > ensuring we are not consuming unnecessary energy.
> > > >
> > > > If approved me and sarthak negi will be working on it as part of KDE
> SoK
> > > > 24. You can also check my proposal(
> > > > https://invent.kde.org/teams/season-of-kde/2024/-/issues/24) and
> > >
> > > sarthak's
> > >
> > > > proposal(https://invent.kde.org/teams/season-of-kde/2024/-/issues/19
> )
> > > >
> > > > I am eager to hear your feedback, answer any questions and discuss
> the
> > >
> > > most
> > >
> > > > effective implementation approach. Thanks for your time and
> > >
> > > consideration.
> > >
> > > Would this be a gitlab thing or be in a separate service?
> > >
> > > How would you implement 1) i.e. how do you know what/when a
> "pre-release"
> > > exactly is?
> > >
> > > Cheers,
> > >
> > >   Albert
>
>
>
>
>

Re: KEcoLab's integration into Okular

[Albert Astals Cid]

El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va escriure:
> Hi Albert,

Please remember to keep the list in copy :)

> So we are planning to integrate this in the gitlab pipeline and are looking
> to leverage `release-tags` (eg tag v 1.0) to identify the release KEcoLab
> runner would automatically run on and additionally the measurement process
> can also be run manually at any time.

Doing the testing on the tag creation may be a bit too late since we only 
create the tag when the application is released, which means if the test finds 
a regression, it's too late since we've already released.

But I guess as a start is not a bad thing, at least we'd know a regression 
happened :D

Speaking of which, how would we know a regression happened? I understand the 
pipeline would fail, but since "noone" is specifically looking at that 
pipeline it would possibly be "lost"? Maybe we can get an email on the mailing 
list? But I guess that's step #2.

Cheers,
  Albert

> 
> Sincerely,
> Aakarsh MJ
> 
> On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid  wrote:
> > El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ va
> > 
> > escriure:
> > > request "reply all"
> > > 
> > > Hello everyone, My name is Aakarsh MJ, I’m contacting you on behalf of
> > 
> > the
> > 
> > > KDE Eco’s KEcoLab team for proposing the integration of KEcoLab into
> > > Okular’s pipeline. There are 2 proposed models (you can also suggest
> > > your
> > > own) which are as follows:
> > > 
> > > 1) Pre-release Testing:
> > > * Every release candidate would be tested for energy consumption.
> > > * Provide information about energy change with the previous versions to
> > > maintain the Blue Angel’s recommended less than 10% increase from the
> > 
> > time
> > 
> > > of certification requirement.
> > > 
> > > 2) Optional Merge Request Testing (MRT)
> > > * Maintainers can opt to run KEcoLab on specific merge requests based on
> > > their potential impact on energy consumption.
> > > * Smaller changes or bug fixes may not require MRT, while large feature
> > > additions could benefit from energy analysis
> > > * This approach allows for targeted testing, while at the same time
> > > ensuring we are not consuming unnecessary energy.
> > > 
> > > If approved me and sarthak negi will be working on it as part of KDE SoK
> > > 24. You can also check my proposal(
> > > https://invent.kde.org/teams/season-of-kde/2024/-/issues/24) and
> > 
> > sarthak's
> > 
> > > proposal(https://invent.kde.org/teams/season-of-kde/2024/-/issues/19)
> > > 
> > > I am eager to hear your feedback, answer any questions and discuss the
> > 
> > most
> > 
> > > effective implementation approach. Thanks for your time and
> > 
> > consideration.
> > 
> > Would this be a gitlab thing or be in a separate service?
> > 
> > How would you implement 1) i.e. how do you know what/when a "pre-release"
> > exactly is?
> > 
> > Cheers,
> > 
> >   Albert

Re: Removing plucker generator ?

[Albert Astals Cid]

El dimecres, 17 de gener de 2024, a les 13:45:03 (CET), Sune Stolborg Vuorela 
va escriure:
> Hi
> 
> While doing changes for KF6, I also touched the plucker generator code a
> bit. And I'm not confident in the code.
> 
> It's c-code originating in 2003.
> It seems to be trusting the input is good.
> I found potential crasher bugs in it by looking at it
> It has no tests
> It doesn't look like the code has met some fuzzy-tester
> 
> If it requires a owner key, it needs to be provided in a configuration file
> somewhere on disk, and trying that ends up with out of bounds writes and
> crashes. The configuration file it tries to open is btw called:
> PLUCKER_CONFIG_DIRFILE_SEPARATOR_CHAR_SSYS_CONFIG_FILE_NAME
> (and stored in a char* malloc'ed to be 40 chars long).
> 
> It has foo = realloc(foo,...); foo[n].bar = ...; Realloc returns null on
> failure.
> 
> It's hard to find test data for it. Any data.
> The homepage of the format seems to have been repurposed many years ago to
> something else.
> 
> I think we should either find someone to take ownership over this and
> promise to invest a significant amount of time into it. Or just remove it.

CC'in Tobias (if that address still works) in case he has some input.

I've never seen any plucker document myself.

Cheers,
  Albert

> 
> /Sune

Re: KEcoLab's integration into Okular

[Albert Astals Cid]

El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ va escriure:
> request "reply all"
> 
> Hello everyone, My name is Aakarsh MJ, I’m contacting you on behalf of the
> KDE Eco’s KEcoLab team for proposing the integration of KEcoLab into
> Okular’s pipeline. There are 2 proposed models (you can also suggest your
> own) which are as follows:
> 
> 1) Pre-release Testing:
> * Every release candidate would be tested for energy consumption.
> * Provide information about energy change with the previous versions to
> maintain the Blue Angel’s recommended less than 10% increase from the time
> of certification requirement.
> 
> 2) Optional Merge Request Testing (MRT)
> * Maintainers can opt to run KEcoLab on specific merge requests based on
> their potential impact on energy consumption.
> * Smaller changes or bug fixes may not require MRT, while large feature
> additions could benefit from energy analysis
> * This approach allows for targeted testing, while at the same time
> ensuring we are not consuming unnecessary energy.
> 
> If approved me and sarthak negi will be working on it as part of KDE SoK
> 24. You can also check my proposal(
> https://invent.kde.org/teams/season-of-kde/2024/-/issues/24) and sarthak's
> proposal(https://invent.kde.org/teams/season-of-kde/2024/-/issues/19)
> 
> I am eager to hear your feedback, answer any questions and discuss the most
> effective implementation approach. Thanks for your time and consideration.

Would this be a gitlab thing or be in a separate service?

How would you implement 1) i.e. how do you know what/when a "pre-release" 
exactly is? 

Cheers,
  Albert

Re: how to unsubscribe this mailing list ?

[Ari Massoudi]

thanks :)

Le dim. 10 déc. 2023 à 23:36, Albert Astals Cid  a écrit :

> See https://mail.kde.org/mailman/listinfo/okular-devel
>
>
>

Re: how to unsubscribe this mailing list ?

[Albert Astals Cid]

See https://mail.kde.org/mailman/listinfo/okular-devel

Re: Removing import Postscript as PDF feature?

[Albert Astals Cid]

El divendres, 24 de novembre de 2023, a les 10:29:22 (CET), Oliver Sander va 
escriure:
> > I'm also trying to flip it around a  bit. If this was proposed today where
> > we have a postscript generator in okular, would we accept this feature?
> Also, don't you get the same functionality by loading the postscript as
> postscript, and then printing it to a file (at least in principle)?  I'd
> consider that way of converting postscript to pdf more natural.

This is a good point, if loading the PS directly gives a similar experience 
than converting the PS to PDF on the fly, then my argument about people being 
sad doesn't apply.

To be honest I have no idea if the functionality is similar, i don't think 
i've ever used the feature.

Cheers,
  Albert

> 
> Best,
> Oliver

Re: Removing import Postscript as PDF feature?

[Albert Astals Cid]

El divendres, 24 de novembre de 2023, a les 9:49:15 (CET), Sune Stolborg 
Vuorela va escriure:
> On Friday, November 24, 2023 12:53:31 AM CET Albert Astals Cid wrote:
> > What do we win by removing the code? It's like 10 lines of code i guess?
> 
> it is just 2 digits lines of code, yes. But there is some bugs in it.
>  - Paper size
>  - memory leaks on conversion failure
>  - no user feedback on conversion failure
>  - Not that good user experience if ps2pdf not available
> 
> I'm also trying to flip it around a  bit. If this was proposed today where
> we have a postscript generator in okular, would we accept this feature?

No, would probably not be accepted, but that's not a fair question, because 
the feature is here, potentially used by people (we should add kuserfeeddback 
to have actual data about this) that will be sad that the feature is removed. 
The fact that it can be done using the command line doesn't matter, we can't 
ask regular users to use the command line, if we do that, we've lost.

> 
> All of this can be fixed, but I'd rather just remove it because I don't yet
> see the value in it.

There's also no need to fix it, the code has existed for 2 decades and AFAIK 
there's no bug about any of those things you mention.

Cheers,
  Albert

> 
> /Sune

Re: Removing import Postscript as PDF feature?

[Oliver Sander]

I'm also trying to flip it around a  bit. If this was proposed today where we
have a postscript generator in okular, would we accept this feature?


Also, don't you get the same functionality by loading the postscript as 
postscript,
and then printing it to a file (at least in principle)?  I'd consider that way
of converting postscript to pdf more natural.

Best,
Oliver


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Removing import Postscript as PDF feature?

[Sune Stolborg Vuorela]

On Friday, November 24, 2023 12:53:31 AM CET Albert Astals Cid wrote:
> What do we win by removing the code? It's like 10 lines of code i guess?

it is just 2 digits lines of code, yes. But there is some bugs in it. 
 - Paper size
 - memory leaks on conversion failure
 - no user feedback on conversion failure
 - Not that good user experience if ps2pdf not available

I'm also trying to flip it around a  bit. If this was proposed today where we 
have a postscript generator in okular, would we accept this feature?

All of this can be fixed, but I'd rather just remove it because I don't yet see 
the value in it.

/Sune

-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Re: Removing import Postscript as PDF feature?

[Albert Astals Cid]

El dimecres, 22 de novembre de 2023, a les 14:01:03 (CET), Sune Stolborg 
Vuorela va escriure:
> Hi
> I was just reading over bits of okular source code and suddenly discovered
> "Import postscript as PDF" in the main menu.
> 
> I'm considering removing it, but before I propose a patch doing it, I would
> love to have some feedback first.
> 
> Reasons to remove:
>  - Okular can open postcript by itself
>  - It clutters up the menu
>  - There is a open bug report that it always uses US Letter as papersize
> when importing, and no gentle way of fixing it without exposing a
> complicated dialog - It is implented by running an external command
> (ps2pdf) to do the heavy lifting
>  - If your platform doesn't have libspectre, it likely also doesn't
> have ps2pdf
>  - if ps2pdf is not found, it is not immediately clear to the user how to
> solve
>  - Error handling in case of ps2pdf failing is nonexisting
> 
> Reasons to keep:
>  - If you have a okular compiled in a nonstandard configuration, but with
> pdf support, you can later install ps2pdf and be able to view postscript
> files anyway
> 
> The feature in question was added back in 2005; that was back when okular
> was kpdf  and has not been touched much since then.
> 
> Any one for?
> Any one against?

What do we win by removing the code? It's like 10 lines of code i guess?

Cheers,
  Albert

> 
> /Sune

Re: Removing import Postscript as PDF feature?

[A. Wik]

On Wed, 22 Nov 2023 at 13:01, Sune Stolborg Vuorela  wrote:
>
> Any one for?
> Any one against?
>

As far as I'm concerned, you can remove it.  My main reason for that
stance is that, as you wrote, the feature is implemented by calling an
external program (ps2pdf), meaning you might as well use that program
in the first place.  However, I'm comfortable using the command line,
and some people who are not might appreciate the feature being part of
okular.

Regards,
Albert Wik.

Re: Okular font selection

[Albert Astals Cid]

El divendres, 10 de novembre de 2023, a les 17:15:57 (CET), A. Wik va 
escriure:
> Hi all,
> 
> It seems I may have come across a bug in Okular, with regard to font
> selection.  Here is a screenshot:
> https://drive.google.com/file/d/178nuOFvWiBOoqmSIs7spAqDrGt2YHAqQ/view?usp=s
> haring
> 
> As you can see from the picture, one of the CourierNew fonts gets
> substituted with
> NimbusMonoPS, and one of the TimesNewRoman fonts does not get mapped
> to Times New Roman but to Times Roman.  Meanwhile, there is no problem
> with Garamond.
> 
> I've tried to debug this with fc-match, but everthing seems correct
> according to it:
> aw@aw-thinkpad:~$ fc-match 'CourierNew'
> cour.ttf: "Courier New" "Regular"
> aw@aw-thinkpad:~$ fc-match 'TimesNewRoman'
> times.ttf: "Times New Roman" "Regular"
> 
> Can anyone shed some light on this?

You had to go and open a bug and now there's two places to talk about this.

Don't do that.

Cheers,
  Albert

> 
> Regards,
> Albert Wik.

Re: [okular] [Bug 477127] review tool settings get lost after reload

[Ari Massoudi]

Hello All,

Is there a way for me to unsubscribe from this email list? I subscribed in
the first place because I thought it was the newsletter of Okular (and I
didn't get it was the list for developers).

Thanks for your help,
Cheers,

Ari

Le ven. 17 nov. 2023 à 11:53, peter josvai  a
écrit :

> https://bugs.kde.org/show_bug.cgi?id=477127
>
> --- Comment #3 from peter josvai  ---
> it functions good now
> I don't now what happened, but the problem had produced itself twice...
>
> I now have checked whether it is just the last modification that gets
> lost...
> I did one modification, saved and reloaded the document (and Okular), and
> it
> didn't get forgotten...
>
>
> so, at this point I cannot reproduce it anymore...
> Sorry for taking your time!!!
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.

Re: Feature request/enquiry: Overprint support

[Bernard Gray]

Hi all,
Following this up to close the loop -

Kevin Ottens from Enioka has completed the work involved to get this
feature request functional.
At the time of writing the patches/PRs are awaiting upstream review:
 - Okular: https://invent.kde.org/graphics/okular/-/merge_requests/764
 - Poppler: https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1411

If anyone is interested in testing, I have backported the patches for
ubuntu 22.04/jammy in this ppa:
 - https://launchpad.net/~bernard-gray/+archive/ubuntu/okular-poppler

Thanks for all the assistance, I'm very glad to report a happy (near) ending :)

Regards,
Bernie

On Fri, 2 Jun 2023 at 15:51, Bernard Gray  wrote:
>
> Hi Oliver,
>
> > to be honest I think you need professional support for this.
> > Overprint support is a bit exotic, and you are very unlikely to find
> > a volunteer with the motivation, the time and the skills to implement this.
> > In a previous email you mentioned that you write on behalf
> > of a company.  I strongly suggest that you ask them for money to hire
> > one of the companies that offers professional Okular support.
>
> No problems, I've reached out to a company we've previously had
> discussions with - if that's not fruitful, do you have any specific
> recommendations? (Happy if you'd prefer to email me directly/off list)
>
> Thanks again for all the assistance btw, this has been valuable in
> honing the scope of work required.
>
> Regards,
> Bernie

Re: Feature request/enquiry: Overprint support

[Bernard Gray]

Hi Michael,
Thanks for the introduction, we are moving ahead with our previous
contact for now, but will certainly look to get in touch for any
future requirements!

Regards,
Bernie

On Mon, 5 Jun 2023 at 18:46, Michael freer  wrote:
>
> @Oliver - thank you for the introduction and for the endorsement, both are 
> much appreciated.
> —-
>
> Hello Bernard
>
> It is a pleasure to meet you, albeit virtually, for the time being anyway.
>
> It would be a pleasure to determine how KDAB can potentially assist you as 
> and when you feel it is appropriate to do so. When you are ready, please make 
> contact via email or phone.
>
> Kind regards
>
> Michael
>
> —
> Michael Freer | michael.fr...@kdab.com | Director of Sales
> KDAB (UK) Ltd., a KDAB Group company
> Mob: +44 (0)7990 065259
> Office: +44 (0)1625 809908
> KDAB - Trusted Software Excellence
>
>
> > On 2 Jun 2023, at 11:20, Oliver Sander  wrote:
> >
> > 
> >>
> >> No problems, I've reached out to a company we've previously had
> >> discussions with - if that's not fruitful, do you have any specific
> >> recommendations? (Happy if you'd prefer to email me directly/off list)
> >
> > My employer has hired KDAB [CCed] several times for Okular/Poppler work,
> > and we have always been very satisfied with the results.

Re: Feature request/enquiry: Overprint support

[Michael freer]

@Oliver - thank you for the introduction and for the endorsement, both are much 
appreciated. 
—-

Hello Bernard

It is a pleasure to meet you, albeit virtually, for the time being anyway. 

It would be a pleasure to determine how KDAB can potentially assist you as and 
when you feel it is appropriate to do so. When you are ready, please make 
contact via email or phone. 

Kind regards

Michael

—
Michael Freer | michael.fr...@kdab.com | Director of Sales
KDAB (UK) Ltd., a KDAB Group company
Mob: +44 (0)7990 065259
Office: +44 (0)1625 809908
KDAB - Trusted Software Excellence


> On 2 Jun 2023, at 11:20, Oliver Sander  wrote:
> 
> 
>> 
>> No problems, I've reached out to a company we've previously had
>> discussions with - if that's not fruitful, do you have any specific
>> recommendations? (Happy if you'd prefer to email me directly/off list)
> 
> My employer has hired KDAB [CCed] several times for Okular/Poppler work,
> and we have always been very satisfied with the results.

Re: Feature request/enquiry: Overprint support

[Bernard Gray]

Hi Oliver,

> to be honest I think you need professional support for this.
> Overprint support is a bit exotic, and you are very unlikely to find
> a volunteer with the motivation, the time and the skills to implement this.
> In a previous email you mentioned that you write on behalf
> of a company.  I strongly suggest that you ask them for money to hire
> one of the companies that offers professional Okular support.

No problems, I've reached out to a company we've previously had
discussions with - if that's not fruitful, do you have any specific
recommendations? (Happy if you'd prefer to email me directly/off list)

Thanks again for all the assistance btw, this has been valuable in
honing the scope of work required.

Regards,
Bernie

Re: Feature request/enquiry: Overprint support

[Bernard Gray]

> poppler does have overprinting support (to a certain extent).  See for example
> the manpage of pdftops.

Thanks Oliver, that's great information -

On Wed, 31 May 2023 at 02:10, Oliver Sander  wrote:
> ...
> > Maybe open a feature request at bugs.kde.org -- that's more easily kept 
> > track of.
>
> That I think is still a good idea.

Turns out, there was already a bug raised in 2006(!):
https://bugs.kde.org/show_bug.cgi?id=126942

I've added links back to this mailing list thread - is there any way I
am able to raise the profile of this ticket to get it looked at
(beyond having this discussion)?

Regards,
Bernie

>
> Best,
> Oliver
>
> >
> > Cheers,
> > Oliver
> >
> >
> > On 29.05.23 21:49, Laura David Hurka wrote:
> >> Hi Bernard,
> >>
> >> I don’t know exactly what overprinting is, or what your requirements are.
> >> I understand it as a feature similar to PDF layers.
> >> Okular has a side panel for layers, you can try it with the last page of 
> >> what
> >> a quick internet search gave me:
> >>
> >> https://www.edcfiresafe.org/wp-content/uploads/2015/12/Using-Layerd-PDFs-with-Sample-Map.pdf
> >>
> >> I assume your requirement is to display the document correctly, only on 
> >> your
> >> screen of your local desktop computer.
> >>
> >> My conclusion is that Poppler (the PDF library normally used by Okular) 
> >> will
> >> need to support “overprinting”.
> >> If a user interface is necessary, that should be a sensible addition to
> >> Okular, similar to how layers already have a user interface.
> >>
> >> Cheers, David
> >>
> >>> Hi everyone,
> >>>
> >>> We are currently supporting a very old version of 32 bit adobe reader on
> >>> our ubuntu 22.04/kde desktops, due to the requirement for support for a 
> >>> PDF
> >>> feature called "Overprint" which is used by our label printing supplier (I
> >>> work for an Australian winery)
> >>>
> >>> [...]
> >>>
> >>> Is this feature something Okular would be interested in developing?
> >>
> >>
> >>


On Wed, 31 May 2023 at 02:10, Oliver Sander  wrote:
>
> > Bernard, can you explain more precisely what it is that you need?
> > Without it I don't think you will get a better answer.
>
> Sorry for this: I just found your last email which gives more information.
> Let me digest those first.
>
> > Maybe open a feature request at bugs.kde.org -- that's more easily kept 
> > track of.
>
> That I think is still a good idea.
>
> Best,
> Oliver
>
> >
> > Cheers,
> > Oliver
> >
> >
> > On 29.05.23 21:49, Laura David Hurka wrote:
> >> Hi Bernard,
> >>
> >> I don’t know exactly what overprinting is, or what your requirements are.
> >> I understand it as a feature similar to PDF layers.
> >> Okular has a side panel for layers, you can try it with the last page of 
> >> what
> >> a quick internet search gave me:
> >>
> >> https://www.edcfiresafe.org/wp-content/uploads/2015/12/Using-Layerd-PDFs-with-Sample-Map.pdf
> >>
> >> I assume your requirement is to display the document correctly, only on 
> >> your
> >> screen of your local desktop computer.
> >>
> >> My conclusion is that Poppler (the PDF library normally used by Okular) 
> >> will
> >> need to support “overprinting”.
> >> If a user interface is necessary, that should be a sensible addition to
> >> Okular, similar to how layers already have a user interface.
> >>
> >> Cheers, David
> >>
> >>> Hi everyone,
> >>>
> >>> We are currently supporting a very old version of 32 bit adobe reader on
> >>> our ubuntu 22.04/kde desktops, due to the requirement for support for a 
> >>> PDF
> >>> feature called "Overprint" which is used by our label printing supplier (I
> >>> work for an Australian winery)
> >>>
> >>> [...]
> >>>
> >>> Is this feature something Okular would be interested in developing?
> >>
> >>
> >>

Re: Feature request/enquiry: Overprint support

[Oliver Sander]

No problems, I've reached out to a company we've previously had
discussions with - if that's not fruitful, do you have any specific
recommendations? (Happy if you'd prefer to email me directly/off list)


My employer has hired KDAB [CCed] several times for Okular/Poppler work,
and we have always been very satisfied with the results.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Feature request/enquiry: Overprint support

[Oliver Sander]

Hi Bernard,


Turns out, there was already a bug raised in 2006(!):
https://bugs.kde.org/show_bug.cgi?id=126942


thanks for finding this.


I've added links back to this mailing list thread - is there any way I
am able to raise the profile of this ticket to get it looked at
(beyond having this discussion)?


to be honest I think you need professional support for this.
Overprint support is a bit exotic, and you are very unlikely to find
a volunteer with the motivation, the time and the skills to implement this.
In a previous email you mentioned that you write on behalf
of a company.  I strongly suggest that you ask them for money to hire
one of the companies that offers professional Okular support.

Best,
Oliver


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Feature request/enquiry: Overprint support

[Oliver Sander]

Bernard, can you explain more precisely what it is that you need?
Without it I don't think you will get a better answer.


Sorry for this: I just found your last email which gives more information.
Let me digest those first.


Maybe open a feature request at bugs.kde.org -- that's more easily kept track 
of.


That I think is still a good idea.

Best,
Oliver



Cheers,
Oliver


On 29.05.23 21:49, Laura David Hurka wrote:

Hi Bernard,

I don’t know exactly what overprinting is, or what your requirements are.
I understand it as a feature similar to PDF layers.
Okular has a side panel for layers, you can try it with the last page of what
a quick internet search gave me:

https://www.edcfiresafe.org/wp-content/uploads/2015/12/Using-Layerd-PDFs-with-Sample-Map.pdf

I assume your requirement is to display the document correctly, only on your
screen of your local desktop computer.

My conclusion is that Poppler (the PDF library normally used by Okular) will
need to support “overprinting”.
If a user interface is necessary, that should be a sensible addition to
Okular, similar to how layers already have a user interface.

Cheers, David


Hi everyone,

We are currently supporting a very old version of 32 bit adobe reader on
our ubuntu 22.04/kde desktops, due to the requirement for support for a PDF
feature called "Overprint" which is used by our label printing supplier (I
work for an Australian winery)

[...]

Is this feature something Okular would be interested in developing?






smime.p7s
Description: S/MIME Cryptographic Signature

Re: Feature request/enquiry: Overprint support

[Bernard Gray]

Hi David,
Thankyou for your informative reply!

On Tue, 30 May 2023 at 05:49, Laura David Hurka  wrote:
>
> Hi Bernard,
>
> I don’t know exactly what overprinting is, or what your requirements are.
> I understand it as a feature similar to PDF layers.

I'm afraid I don't exactly understand it either, but from the link I
posted in the original email[1] it seems to be tied to (some) physical
printers and the way the PDF defines the separation of CMYK toners for
certain elements.
The problem is that the screen viewers (okular, et al) don't render
this to the screen correctly, creating the multi-layered, unclear font
in the example I sent


> Okular has a side panel for layers, you can try it with the last page of what
> a quick internet search gave me:
>
> https://www.edcfiresafe.org/wp-content/uploads/2015/12/Using-Layerd-PDFs-with-Sample-Map.pdf

Great, that was useful to see how okular implements layers, however it
does not recognise the Overprint features in the PDF as layers (there
was no layers tab appearing in the sidebar of okular in my example
PDF[2])


> I assume your requirement is to display the document correctly, only on your
> screen of your local desktop computer.

Correct


> My conclusion is that Poppler (the PDF library normally used by Okular) will
> need to support “overprinting”.

I don't really understand how the library would interact with the
viewer in this case, but I am happy to pose the question to the
poppler team separately
Do you have any recommendation on how best to contact them/frame the request?

> If a user interface is necessary, that should be a sensible addition to
> Okular, similar to how layers already have a user interface.


This is the user interface implemented in AdobeReader 9 - Via the
program preferences, setting "Use Overprint Preview: [Always |
Automatic]" displays the PDF correctly
https://drive.google.com/file/d/1ix9ZPtq8LD4EosaKZXFF5aRCVnEQv_bM/view?usp=sharing

> Cheers, David


[1]: https://pdfa.org/understanding-overprint/
[2]: 
https://drive.google.com/file/d/1WGlly-EvzQl1Jhj39R9hvJ16CIgVZD5j/view?usp=share_link

>
> > Hi everyone,
> >
> > We are currently supporting a very old version of 32 bit adobe reader on
> > our ubuntu 22.04/kde desktops, due to the requirement for support for a PDF
> > feature called "Overprint" which is used by our label printing supplier (I
> > work for an Australian winery)
> >
> > [...]
> >
> > Is this feature something Okular would be interested in developing?

Re: Feature request/enquiry: Overprint support

[Oliver Sander]

Hi,

poppler does have overprinting support (to a certain extent).  See for example
the manpage of pdftops.

Bernard, can you explain more precisely what it is that you need?
Without it I don't think you will get a better answer.

Maybe open a feature request at bugs.kde.org -- that's more easily kept track 
of.

Cheers,
Oliver


On 29.05.23 21:49, Laura David Hurka wrote:

Hi Bernard,

I don’t know exactly what overprinting is, or what your requirements are.
I understand it as a feature similar to PDF layers.
Okular has a side panel for layers, you can try it with the last page of what
a quick internet search gave me:

https://www.edcfiresafe.org/wp-content/uploads/2015/12/Using-Layerd-PDFs-with-Sample-Map.pdf

I assume your requirement is to display the document correctly, only on your
screen of your local desktop computer.

My conclusion is that Poppler (the PDF library normally used by Okular) will
need to support “overprinting”.
If a user interface is necessary, that should be a sensible addition to
Okular, similar to how layers already have a user interface.

Cheers, David


Hi everyone,

We are currently supporting a very old version of 32 bit adobe reader on
our ubuntu 22.04/kde desktops, due to the requirement for support for a PDF
feature called "Overprint" which is used by our label printing supplier (I
work for an Australian winery)

[...]

Is this feature something Okular would be interested in developing?






smime.p7s
Description: S/MIME Cryptographic Signature

Re: Feature request/enquiry: Overprint support

[Laura David Hurka]

Hi Bernard,

I don’t know exactly what overprinting is, or what your requirements are.
I understand it as a feature similar to PDF layers.
Okular has a side panel for layers, you can try it with the last page of what 
a quick internet search gave me:

https://www.edcfiresafe.org/wp-content/uploads/2015/12/Using-Layerd-PDFs-with-Sample-Map.pdf

I assume your requirement is to display the document correctly, only on your 
screen of your local desktop computer.

My conclusion is that Poppler (the PDF library normally used by Okular) will 
need to support “overprinting”.
If a user interface is necessary, that should be a sensible addition to 
Okular, similar to how layers already have a user interface.

Cheers, David

> Hi everyone,
> 
> We are currently supporting a very old version of 32 bit adobe reader on
> our ubuntu 22.04/kde desktops, due to the requirement for support for a PDF
> feature called "Overprint" which is used by our label printing supplier (I
> work for an Australian winery)
> 
> [...]
> 
> Is this feature something Okular would be interested in developing?

Re: Okular with GnuPG / Gpg4win

[Albert Astals Cid]

El dimecres, 17 de maig de 2023, a les 10:56:38 (CEST), Andre Heinecke va 
escriure:
> Hi,
> 
> On Tuesday 16 May 2023 23:55:00 CEST Albert Astals Cid wrote:
> > The text looks reasonable to me, but i guess we'd definitely want some
> > input from the KDE Promo folks. Want me to involve them or will you?
> 
> I already did start on that yesterday.
> https://marc.info/?l=kde-promo=168423425626159=2
> 
> Btw. my second mail in the thread gives some additional rationale why the
> GnuPG integration is useful for us so it might be worth a read.
> 
> > I can see that how that would make sense for translation but i don't see
> > how this particular wording makes sense to be in the Okular repository.
> > 
> > Imagine we get 10 different downstreams like you, we would need 10
> > different strings.
> > 
> > One thing that comes to mind is we could come up with some kind of "these
> > functionalities have been disabled" based on
> > FORCE_NOT_REQUIRED_DEPENDENCIES have been set. (Or maybe just a generic
> > one if any has been set?)
> 
> I understand your point In Kleopatra we try to avoid that, too.
> 
> What do you think about two options:
> 
> option(OKULAR_UI_TITLE "Use an alternative title for the Okular UI. Please
> consider when using FORCE_NOT_REQUIRED_DEPENDENCIES" "Okular")
> option(SHOW_REDUCED_FUNCTIONALITY_WARNING "Show a warning on first run and
> in the about dialog that this Okular comes with a reduced functionality
> set." ((NOT FORCE_NOT_REQUIRED_DEPENDENCIES) AND (NOT
> FORCE_NOT_REQUIRED_DEPENDENCIES STREQUAL "")))
> 
> That way we could have a generic warning because I don't think
> our users will understand what the libraries mean and explaining that would
> be too much. And a distro that might want to make only a minor change like
> not shipping CHM support for some reason can set this option to "OFF" to
> avoid such a warning.
> 
> The reference to the Windows store should also be added with a
> Q_OS_WIN ifdef and maybe for Linux with an "obtain from your Distribution".
> 
> OKULAR_UI_TITLE we can then use to bring in "Okular (GnuPG Edition)".
> 
> Probably best if I create an MR and we can discuss this there.

Yes.

Cheers,
  Albert

> 
> Best Regards,
> Andre

Re: Okular with GnuPG / Gpg4win

[Andre Heinecke]

Hi,

On Tuesday 16 May 2023 23:55:00 CEST Albert Astals Cid wrote:
> The text looks reasonable to me, but i guess we'd definitely want some input 
> from the KDE Promo folks. Want me to involve them or will you?

I already did start on that yesterday. 
https://marc.info/?l=kde-promo=168423425626159=2

Btw. my second mail in the thread gives some additional rationale why the GnuPG
 integration is useful for us so it might be worth a read.

> I can see that how that would make sense for translation but i don't see how 
> this particular wording makes sense to be in the Okular repository.
> 
> Imagine we get 10 different downstreams like you, we would need 10 different 
> strings.
> 
> One thing that comes to mind is we could come up with some kind of "these 
> functionalities have been disabled" based on FORCE_NOT_REQUIRED_DEPENDENCIES 
> have been set. (Or maybe just a generic one if any has been set?) 

I understand your point In Kleopatra we try to avoid that, too.

What do you think about two options:

option(OKULAR_UI_TITLE "Use an alternative title for the Okular UI. Please 
consider when using FORCE_NOT_REQUIRED_DEPENDENCIES" "Okular")
option(SHOW_REDUCED_FUNCTIONALITY_WARNING "Show a warning on first run and in 
the about dialog that this Okular comes with a reduced functionality set." 
((NOT FORCE_NOT_REQUIRED_DEPENDENCIES) AND (NOT FORCE_NOT_REQUIRED_DEPENDENCIES 
STREQUAL "")))

That way we could have a generic warning because I don't think
our users will understand what the libraries mean and explaining that would be
too much. And a distro that might want to make only a minor change
like not shipping CHM support for some reason can set this option to "OFF" to 
avoid
such a warning.

The reference to the Windows store should also be added with a
Q_OS_WIN ifdef and maybe for Linux with an "obtain from your Distribution".

OKULAR_UI_TITLE we can then use to bring in "Okular (GnuPG Edition)".

Probably best if I create an MR and we can discuss this there.

Best Regards,
Andre

-- 
GnuPG.com - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608, www.g10code.com.

GnuPG e.V., Rochusstr. 44, D-40479 Düsseldorf.  VR 11482 Düsseldorf
Vorstand: W.Koch, B.Reiter, A.HeineckeMail: bo...@gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-211-28010702

signature.asc
Description: This is a digitally signed message part.

Re: Okular with GnuPG / Gpg4win

[Albert Astals Cid]

El divendres, 12 de maig de 2023, a les 12:40:23 (CEST), Andre Heinecke va 
escriure:
> Hi,
> 
> our integration of Okular anxd GnuPG (and later on GnuPG VS-Desktop) is
> nearly finished. Not everything is upstream yet but we see no roadblocks on
> the way that might cause us to abort so we would like to go ahead and
> announce this a bit more.
> 
> Attached is a first draft of a statement about why we started to work on
> this.

The text looks reasonable to me, but i guess we'd definitely want some input 
from the KDE Promo folks. Want me to involve them or will you?

> First of I want to say a big thank you to everyone who helped with reviewing
> etc. and for the excellent design of Okular which allowed a very modular
> build.
> 
> But, this is a slight problem because we are targeting a high security
> environment we want to limit the attack surface as much as possible. This
> means that we have stripped down Okular quite a lot.
> 
> - It will have only the poppler generator.
> - Basically no optional dependencies. (No JavaScript)
> - No Phonon for Media (patches to cleanly make that optional are incoming, I
> have hacked it for now).
> 
> Additionally we carry some patches which allow us to strip down framework
> inter dependencies and brutally hack some parts like KIO to come for example
> without DBus support.
> 
> As such I think it would be unfair of us to call this just "Okular" and give
> you a possibly bad name.
> 
> My suggestion is the following:
> - Use the name "Okular (GnuPG Edition)" in user visible strings, like the
> start Menu, Window Title, About Dialog etc.
> - Change the bug tracker URL to dev.gnupg.org for us (should be obvious).

That seems reasonable to me.

> 
> And finally to add a Message Box on the first launch and add a Text in the
> about dialog to promote the full featured Okular which I draft as
> following:
> 
> --
> Okular in general is a lightweight and highly secure document viewer for
> many document formats.
> 
> To reduce the attack surface even further the GnuPG Edition is stripped
> down to only support PDF documents without any active content.
> 
> For the best User Experience you can safely install the fully featured
> Okular from the https://apps.microsoft.com/store/detail/okular/
> 9N41MSQ1WNM8">Microsoft Store
> --
> 
> If this seems agreeable to you I would open a merge request regarding
> something like this as a build switch. I would like to have the text
> included upstream instead of patching it in for translation / wording
> support etc.

I can see that how that would make sense for translation but i don't see how 
this particular wording makes sense to be in the Okular repository.

Imagine we get 10 different downstreams like you, we would need 10 different 
strings.

One thing that comes to mind is we could come up with some kind of "these 
functionalities have been disabled" based on FORCE_NOT_REQUIRED_DEPENDENCIES 
have been set. (Or maybe just a generic one if any has been set?) 

Cheers,
  Albert



> 
> I don't think that a parallel installation of two Okulars will make much
> sense except in very specific use cases (e.g. If you use Okular (GnuPG
> Edition) to open PDF's from Mails and the regular Okular as default). But
> it is possible and no Problem.
> 
> 
> Best Regards,
> Andre

Re: GSoC proposal submitted

[Shivodit Gill]

Thanks for the feedback! Hoping everything goes smoothly. :)

Thanks,
Shivodit

On 4/4/23 02:31, Albert Astals Cid wrote:
> El dilluns, 3 d’abril de 2023, a les 22:08:45 (CEST), Shivodit Gill va 
> escriure:
>> Hello,
>>
>> I have submitted my GSoC proposal on the online portal, please take a
>> look at it.
> 
> I've had a look at it, seems reasonable :)
> 
> Best Regards,
>   Albert
> 
>>
>> Thanks,
>> Shivodit
> 
> 
> 
> 

Re: GSoC proposal submitted

[Albert Astals Cid]

El dilluns, 3 d’abril de 2023, a les 22:08:45 (CEST), Shivodit Gill va 
escriure:
> Hello,
> 
> I have submitted my GSoC proposal on the online portal, please take a
> look at it.

I've had a look at it, seems reasonable :)

Best Regards,
  Albert

> 
> Thanks,
> Shivodit

Re: Okular PlantUML Support

[Albert Astals Cid]

El dijous, 30 de març de 2023, a les 8:39:28 (CEST), Signal Kirigami va 
escriure:
> Recently I'm trying to add PlantUML support on okular part. PlantUML is a
> component to generate diagrams, and many markdown editors, such as QOwnNote
> and VSCode, support it.
> 
> The code is here: https://invent.kde.org/prcups/okular/-/tree/master.
> 
> Current version have slow speed and will freeze when generating, because
> markdown generator can't be dynamically update. I think I can do more on
> this field, like creating a plugin platform, or change backend of
> generator. 

We already have a plugin platform, generators are plugins.

> I need some advice.

You need to be more precise in which advice you need :)

Cheers,
  Albert

Re:

[Shivodit Gill]

Thanks for the info, I'll look into the GlobalParams code.

As a side note, I'm having trouble figuring out why the icon rendering
isn't working, as I haven't gotten to setting up a debug environment
fully. Do you have any tips?

Thanks,
Shivodit

On 3/27/23 13:25, Albert Astals Cid wrote:
> 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 

Re:

[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 

Re:

[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 

Re: segmentation fault 22.04.3

[Oliver Sander]

Thank you Albert. The pdf file is not relevant here though. Not when other 
viewers such as xpdf handle the file without a problem.


The pdf file is certainly relevant.  It is very difficult to fix a crash
in a particular file without having the file.

Please open an issue on bugs.kde.org and attach the file.

Best,
Oliver


smime.p7s
Description: S/MIME Cryptographic Signature

Re:

[Albert Astals Cid]

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

Re:

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

Re: segmentation fault 22.04.3

[Carlos]

On Sat, Mar 18, 2023 at 11:46:21AM +0100, Albert Astals Cid wrote:
> El dissabte, 18 de març de 2023, a les 6:34:56 (CET), Carlos va escriure:
> > Hello list:
> > 
> > I just came across a segmentation fault. I didn't check for similar errors,
> > but I thought of posting it either way. Okular crashes every time with the
> > same file.
> > 
> > Starting program: /usr/bin/okular
> > [New LWP 22049]
> > [New LWP 22050]
> > [New LWP 22051]
> > [LWP 22051 exited]
> > [New LWP 22055]
> > [New LWP 22056]
> > [LWP 22055 exited]
> > [LWP 22056 exited]
> > [New LWP 22057]
> > [New LWP 22058]
> > [LWP 22057 exited]
> > [New LWP 22059]
> > 
> > Thread 8 "Okular::TextPag" received signal SIGSEGV, Segmentation fault.
> > [Switching to LWP 22058]
> > 0x7fffe76b5e4a in ?? () from /usr/lib/libpoppler.so.121
> 
> Please file  bug in bugs.kde.org add a longer backtrace (ideally with 
> symbols) 

I'll do that. I don't know about the «symbols» part, as there are only ?? and 
() on the backtrace. 

> and attach the file that is causing the crash.
> 
> Cheers,
>   Albert

Thank you Albert. The pdf file is not relevant here though. Not when other 
viewers such as xpdf handle the file without a problem. 


-- 
Overflow on /dev/null, please empty the bit bucket.

Re: segmentation fault 22.04.3

[Albert Astals Cid]

El dissabte, 18 de març de 2023, a les 6:34:56 (CET), Carlos va escriure:
> Hello list:
> 
> I just came across a segmentation fault. I didn't check for similar errors,
> but I thought of posting it either way. Okular crashes every time with the
> same file.
> 
> Starting program: /usr/bin/okular
> [New LWP 22049]
> [New LWP 22050]
> [New LWP 22051]
> [LWP 22051 exited]
> [New LWP 22055]
> [New LWP 22056]
> [LWP 22055 exited]
> [LWP 22056 exited]
> [New LWP 22057]
> [New LWP 22058]
> [LWP 22057 exited]
> [New LWP 22059]
> 
> Thread 8 "Okular::TextPag" received signal SIGSEGV, Segmentation fault.
> [Switching to LWP 22058]
> 0x7fffe76b5e4a in ?? () from /usr/lib/libpoppler.so.121

Please file  bug in bugs.kde.org add a longer backtrace (ideally with symbols) 
and attach the file that is causing the crash.

Cheers,
  Albert

Re: Digital signature: font & content of the rectangle

[Oliver Sander]

Hi Guillaume,

most of what is missing has been implemented in

  https://invent.kde.org/graphics/okular/-/merge_requests/537

Best,
Oliver

On 15.03.23 18:31, Guillaume Gheysen wrote:

Dear Okular developers,

I am using Okular to e-sign documents (using Belgian Eid) and I really 
appreciate your work. However, I don't find the options to configure the 
signature drawn on the pdf (font, content, etc.) and I need to make a huge 
rectangle to have a visible signature (which is not often possible). It is 
possible to have information about this configuration or do you know when this 
feature will be available ? Thank you.

Best regards,

Guillaume Gheysen


smime.p7s
Description: S/MIME Cryptographic Signature

Re:

[Albert Astals Cid]

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

Re:

[Shivodit Gill]

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

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

Thanks,
Shivodit


> Cheers,
>   Albert
> 
>>
>> Thanks,
>> Shivodit
> 
> 
> 
> 

Re:

[Albert Astals Cid]

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.

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

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

Cheers,
  Albert

> 
> Thanks,
> Shivodit

Re: Runtime error "you need to call Settings::instance before using"

[Martin Schnitkemper]

Am Samstag, 25. Februar 2023, 11:41:42 CET schrieb Albert Astals Cid:

> Why are you adding PDF only options to the general config file and general
> config dialog instead of to the PDF generator config file and PDF generator
> config dialog/page?

Moved the configuration to the Backend Configuration, looks now like this:
https://invent.kde.org/martin-de/okular/uploads/82757d49a7fe7daa4ffa872f5f6ca4b6/Screenshot_20230225_144426.png

It seems to work now: the configuration is saved and can be retrieved and set
as default before printing, and the print dialog no longer crashes after
invoking it.

Should I create a merge request now?

Cheers,
Martin

Re: Runtime error "you need to call Settings::instance before using"

[Albert Astals Cid]

El divendres, 24 de febrer de 2023, a les 12:34:59 (CET), Martin Schnitkemper 
va escriure:
> Am Donnerstag, 23. Februar 2023, 23:32:15 CET schrieben Sie:
> 
> Hello Albert,
> 
> > Please push your code as a Merge Request so we can see it, much easier to
> > comment on code when we can see it :)
> 
> Thank you for your response.

Please keep the list on copy :)

> 
> I forked the project and created a branch:
> https://invent.kde.org/martin-de/okular/-/tree/wish%23463732
> 
> There you are able to review the code, these are the changes:
> https://invent.kde.org/martin-de/okular/-/commit/1df9d5a500241b0cfae860b1e1b
> d1d604dde7439

Why are you adding PDF only options to the general config file and general 
config 
dialog instead of to the PDF generator config file and PDF generator config 
dialog/page?

> 
> I opend also an issue where I described the problem more detailed:
> https://invent.kde.org/martin-de/okular/-/issues/1
> 
> You can leave your comments there, since I dropped myself from the
> mailinglist due to the traffic.

Which trafic? the bug emails? You need to learn about email filtering :)

Cheers,
  Albert

> 
> Cheers,
> Martin

Re: Runtime error "you need to call Settings::instance before using"

[Albert Astals Cid]

El dijous, 19 de gener de 2023, a les 9:43:30 (CET), Martin Schnitkemper va 
escriure:
> Hello,
> 
> I tried to extend okular to save PDF-Print-Options (wish #463732).  All
> works well so far, I added a new item in the configuration dialog and the
> new variable "PageScaleMode" is written to and read from "okularpartrc",
> but I am not able to assign the value of "Okular::Settings::pageScaleMode"
> to "m_scaleMode->setCurrentIndex" in module "generator_pdf.cpp".
> 
> Compilation is successful, but it crashes on runtime after opening the print
> dialog. Message on terminal is "you need to call Settings::instance before
> using".
> 
> I am not too familiar with C++ coding and it is my first try to extend an
> application.  I inspected already the other modules of the project where the
> developers used "Okular::Settings::" in a similar & working way, but I
> could not find out so far, where the instance has been set for a proper
> usage.
> 
> Can anyone tell me what I missed, or guide me to a code example of the
> okular project where I can see how to get right access to the
> "Okular::Settings::"?

Please push your code as a Merge Request so we can see it, much easier to 
comment on code when we can see it :)

Cheers,
  Albert

> 
> Thank you in advance for your support,
> Martin

Re: Publish Okular for Windows using new script

[Albert Astals Cid]

El dilluns, 6 de febrer de 2023, a les 17:32:58 (CET), Ingo Klöcker va 
escriure:
> On Donnerstag, 2. Februar 2023 23:31:29 CET Albert Astals Cid wrote:
> > El dimarts, 31 de gener de 2023, a les 16:23:43 (CET), Ingo Klöcker va
> > 
> > escriure:
> > > * There are 5 screenshots in Microsoft Store which are different from
> > > the
> > > screenshots referenced in the AppStream data. On one hand this allows
> > > using
> > > Windows-specific screenshots for the Microsoft Store. On the other hand
> > > you
> > > miss the opportunity for translated captions which are provided by the
> > > AppStream data. Maybe consider using the same screenshots because I
> > > guess
> > > that the look of Okular on Windows shouldn't be that different than the
> > > one
> > > on Linux except for different windows decorations.
> > 
> > I think this is a big deal for Windows users, they are already scared
> > enough installing some weird app, worst if we show them the wrong window
> > decoration in the screenshots.
> > 
> > Maybe we can use custom tags for the windows screenshots?
> > 
> > https://community.kde.org/Guidelines_and_HOWTOs/AppStream#KDE_customs_tags
> 
> Custom tags seem to be limited to key-value pairs. 

:/

> An alternative would be
> to add the Windows screenshots to the screenshots tag, but without
> type="default" (or any other type) and instead with platform="windows"
> (Harald opened an issue for this some time ago:
> https://github.com/ximion/appstream/issues/390).
> 
> We will have to change the generator for apps.kde.org to skip screenshots
> without default type if we don't want to see Windows screenshots on
> apps.kde.org.

But that will just work for apps.kde.org there's "infinite" other consumers of 
appstream files out there (discover, flathub, gnome software), we can't "fix" 
those

> 
> BTW, I don't see the Windows screenshots in
> https://cdn.kde.org/screenshots/okular/
> Where are they "hidden"?

I guess in the Windows Store :D

Cheers,
  Albert

> 
> Regards,
> Ingo

Re: Publish Okular for Windows using new script

[Ingo Klöcker]

On Donnerstag, 2. Februar 2023 23:31:29 CET Albert Astals Cid wrote:
> El dimarts, 31 de gener de 2023, a les 16:23:43 (CET), Ingo Klöcker va
> escriure:
> > * There are 5 screenshots in Microsoft Store which are different from the
> > screenshots referenced in the AppStream data. On one hand this allows
> > using
> > Windows-specific screenshots for the Microsoft Store. On the other hand
> > you
> > miss the opportunity for translated captions which are provided by the
> > AppStream data. Maybe consider using the same screenshots because I guess
> > that the look of Okular on Windows shouldn't be that different than the
> > one
> > on Linux except for different windows decorations.
> 
> I think this is a big deal for Windows users, they are already scared enough
> installing some weird app, worst if we show them the wrong window
> decoration in the screenshots.
> 
> Maybe we can use custom tags for the windows screenshots?
> 
> https://community.kde.org/Guidelines_and_HOWTOs/AppStream#KDE_customs_tags

Custom tags seem to be limited to key-value pairs. An alternative would be to 
add the Windows screenshots to the screenshots tag, but without type="default" 
(or any other type) and instead with platform="windows" (Harald opened an 
issue for this some time ago: https://github.com/ximion/appstream/issues/390).

We will have to change the generator for apps.kde.org to skip screenshots 
without default type if we don't want to see Windows screenshots on 
apps.kde.org.

BTW, I don't see the Windows screenshots in
https://cdn.kde.org/screenshots/okular/
Where are they "hidden"?

Regards,
Ingo

signature.asc
Description: This is a digitally signed message part.

Re: Publish Okular for Windows using new script

[Albert Astals Cid]

El dimarts, 31 de gener de 2023, a les 16:23:43 (CET), Ingo Klöcker va 
escriure:
> Hi Okular devs,
> 
> as you may have seen there is now a way to publish your application semi-
> automatically on the Microsoft Store:
> https://blogs.kde.org/2023/01/16/neochat-published-microsoft-store
> 
> Aleix suggested that you could give it a try, so that I can get feedback
> what should be improved.
> 
> The idea of the script is to use the information from the AppStream data
> additionally to the .appxupload package so that one does not have to fill in
> the information manually.
> 
> Comparing the AppStream data for Okular with the information published in
> the Microsoft Store I'm seeing the following:
> 
> * The Microsoft Store contains only a listing in English. The script would
> create listings for all languages (supported by Microsoft Store) for which
> there is a translation of the description in the AppStream data.
> 
> * The description in Microsoft Store seems to be identical to the
> description in the AppStream data, but without the list of Features.
> 
> * The list of Features in Microsoft Store seems to be identical to the list
> of Features in the description in the AppStream data.
> 
> * What's New? in Microsoft Store contains "Updated to ". In the
> AppStream data the first (newest) release entry has no description. Quite
> frankly, "Update to " isn't really very helpful information for the
> users. Listing new features would be much more interesting (for all
> consumers of the AppStream data).

I used to add links to the changelog (i.e. https://kde.org/announcements/
changelogs/gear/22.12.0/#okular), if the last one doesn't is because i got 
bored

> 
> * There are 5 screenshots in Microsoft Store which are different from the
> screenshots referenced in the AppStream data. On one hand this allows using
> Windows-specific screenshots for the Microsoft Store. On the other hand you
> miss the opportunity for translated captions which are provided by the
> AppStream data. Maybe consider using the same screenshots because I guess
> that the look of Okular on Windows shouldn't be that different than the one
> on Linux except for different windows decorations.

I think this is a big deal for Windows users, they are already scared enough 
installing some weird app, worst if we show them the wrong window decoration 
in the screenshots.

Maybe we can use custom tags for the windows screenshots?

https://community.kde.org/Guidelines_and_HOWTOs/AppStream#KDE_customs_tags

Cheers,
  Albert

> 
> * The entry in the Microsoft Store lists Search terms. AppStream supports
>  (and the script uses those), but Okular's AppStream data doesn't
> list any keywords.
> 
> For a first try you may want to run the script as follows:
> 
> python3 submit-to-microsoft-store.py -vv --skip-commit \
> --keep description,images org.kde.okular 
> 
> so that the description (for the English listing) and the images are not
> overwritten by the information found in the AppStream data. Moreover, the
> --skip-commit option will allow you to check the submission in Partner
> Center before it is actually submitted for publication.
> 
> Note that you need special credentials to actually use this script (as
> mentioned in the documentation). You need to ask Ben for them. (Of course, I
> could also give them to you, but it's better to keep Ben in the loop.) In
> the future, the script is supposed to be run on invent so that we do not
> have to hand out credentials to anyone/everyone.
> 
> Regards,
> Ingo

Re: Possible to change scroll refresh rate to match monitor

[Tim Hanson]

Interesting .. I suspected as much, but thank you for confirming.

I do have one monitor, but yes for whatever reason the display manager
starts up at 60, and the Xsession runs at 120 Hz.

Nonetheless, can confirm that kile scrolls a pdf smoothly at 120Hz in the
preview pane.
What you said makes sense regarding line scrolling in kate -- also smooth /
instantaneous.

Could it be a performance issue?  Seems unlikely as Okular is not
saturating the CPU (a Ryzen 9 5950x...), and scrolling should be pretty
straightforward (unsure how much rendering is batched internally, though).

Cheers,
Tim

Date: Sat, 07 Jan 2023 10:47:51 +0100
From: David Hurka 
To: okular-devel@kde.org
Subject: Re: Possible to change scroll refresh rate to match monitor
(e.g. 120Hz, 144Hz)
Message-ID: <2285352.ElGaqSPkdT@doro>
Content-Type: text/plain; charset="UTF-8"

> Is there some way to get okular to refresh the page faster?
> It seems fixed at 60hz.

Its not possible from within Okular.
According to QScroller documentation, there is a global animation timer
which
sets the update rate.
This timer should match the frame rate of the screen, but apparently that
doesn’t work.
(Maybe you have more than one monitor, or the monitor changes framerate
after
startup, or Qt fails to detect it correctly.)

> Of note other KDE / qt apps refresh at the monitor rate
> (konsole, kate, kile)

It surprises me, because they use either line-wise scrolling, which happens
instantly, or Okular.
If it works in the Kile document preview, that means Kile is better than
the
Okular shell in detecting the framerate.

Re: Possible to change scroll refresh rate to match monitor (e.g. 120Hz, 144Hz)

[David Hurka]

> Is there some way to get okular to refresh the page faster?
> It seems fixed at 60hz.

Its not possible from within Okular.
According to QScroller documentation, there is a global animation timer which 
sets the update rate.
This timer should match the frame rate of the screen, but apparently that 
doesn’t work.
(Maybe you have more than one monitor, or the monitor changes framerate after 
startup, or Qt fails to detect it correctly.)

> Of note other KDE / qt apps refresh at the monitor rate
> (konsole, kate, kile)

It surprises me, because they use either line-wise scrolling, which happens 
instantly, or Okular.
If it works in the Kile document preview, that means Kile is better than the 
Okular shell in detecting the framerate.

Re: Blue Angel info | include in manual or "About" info-box?

[Albert Astals Cid]

El dimecres, 7 de desembre de 2022, a les 10:36:29 (CET), Joseph P. De Veaugh-
Geiss va escriure:
> Hello,
> 
> On 12/4/22 23:47, Albert Astals Cid wrote:
> > I don't see how to make it fit in the About dialog though. The About
> > dialog is not very customizable (on purpose, so that all apps show the
> > same).
> > 
> > One option is to add it as "Other" text, but IMHO it's a bit too
> > prominent,
> > before the copyright and okular webpage link
> > https://i.imgur.com/ZkRIoTr.png
> > 
> > The other option is have it in the "Thanks" section, which is semantically
> > wrong (e.g. the web link tooltip says "Visit the contributors page")
> > https://i.imgur.com/VbkajK2.png
> > 
> > Maybe we should just go for the manual?
> 
> I noticed that different applications have different tabs in the Help >
> About X info box. For instance: Dolphin has "About", "Components,
> "Authors", while Kate has those plus "Thanks To".
> 
> Could it be worth adding a "Sustainabaility" / "Eco" tab? This would be
> a place to include information about Blue Angel eco-certification and
> other energy measurements, or aspects of the software which make it more
> sustainable (runs on older hardware, freedom from advertising, etc.)?
> 
> I think this idea fits well with the sustainability goal, in particular
> "highlighting where our software is already sustainably designed".
> 
> https://community.kde.org/Goals/Sustainable_Software
> 
> What do you think?

The only thing applications can add is what i told you. Adding new tabs is 
outside the applications scope and would need changes in kcoreaddons and 
kxmlgui (which are out of scope to discuss here).

Cheers,
  Albert

> 
> Cheers,
> Joseph

Re: Blue Angel info | include in manual or "About" info-box?

[Joseph P. De Veaugh-Geiss]

Hello,

On 12/4/22 23:47, Albert Astals Cid wrote:

I don't see how to make it fit in the About dialog though. The About dialog is
not very customizable (on purpose, so that all apps show the same).

One option is to add it as "Other" text, but IMHO it's a bit too prominent,
before the copyright and okular webpage link
https://i.imgur.com/ZkRIoTr.png

The other option is have it in the "Thanks" section, which is semantically
wrong (e.g. the web link tooltip says "Visit the contributors page")
https://i.imgur.com/VbkajK2.png

Maybe we should just go for the manual?


I noticed that different applications have different tabs in the Help > 
About X info box. For instance: Dolphin has "About", "Components, 
"Authors", while Kate has those plus "Thanks To".


Could it be worth adding a "Sustainabaility" / "Eco" tab? This would be 
a place to include information about Blue Angel eco-certification and 
other energy measurements, or aspects of the software which make it more 
sustainable (runs on older hardware, freedom from advertising, etc.)?


I think this idea fits well with the sustainability goal, in particular 
"highlighting where our software is already sustainably designed".


https://community.kde.org/Goals/Sustainable_Software

What do you think?

Cheers,
Joseph

--
Joseph P. De Veaugh-Geiss
BE4FOSS Project and Community Manager (KDE Eco)
OpenPGP: 8FC5 4178 DC44 AD55 08E7 DF57 453E 5746 59A6 C06F

---
KDE Eco: Building Energy-Efficient Free Software!

Website: https://eco.kde.org
Mastodon: @be4foss@floss.social
Mailing list: 
https://mail.kde.org/cgi-bin/mailman/listinfo/energy-efficiency

Matrix: https://webchat.kde.org/#/room/#energy-efficiency:kde.org
Forum: https://forum.kde.org/viewforum.php?f=334

RE: [okular] [Bug 434777] [Snap] Okular does not open in new tab but window

[andreas-naumann]

To me, that looks like you are using different okular versions with different 
settings. Maybe one is snap and one from the system?Von meinem/meiner Galaxy 
gesendet
 Ursprüngliche Nachricht Von: bugzilla_nore...@kde.org Datum: 
07.12.22  09:50  (GMT+01:00) An: okular-devel@kde.org Betreff: [okular] [Bug 
434777] [Snap] Okular does not open in new tab but
  window https://bugs.kde.org/show_bug.cgi?id=434777--- Comment #3 from 
giamm...@hotmail.com ---I have just noticed that if a pdf is opened via right 
click -> open withanother application -> Okular, instead of double-clicking, 
the file is actuallyopened in a tab of the already opened Okular. How is it 
possible to code thisas default behaviour?-- You are receiving this mail 
because:You are the assignee for the bug.

Re: Blue Angel info | include in manual or "About" info-box?

[Albert Astals Cid]

El divendres, 2 de desembre de 2022, a les 8:11:50 (CET), Joseph P. De Veaugh-
Geiss va escriure:
> Hi!
> 
> On 12/2/22 00:05, Albert Astals Cid wrote:
> > I'm not against it, but what's the actual benefit of having that mention?
> > 
> > I can see it's appeal on the webpage, it tells people we're serious, a
> > good
> > app, etc etc so it's a "selling point"
> > 
> > But on the manual/about box, the person is already using the app, so they
> > don't need to be sold on it.
> 
> I can see at least two reasons to include it there:
> 
> - Many users may be using Okular and not know it has been eco-certified.
> This would be a way to inform them about certification if they do not go
> to the main website.
> 
> - As more KDE aps are certified or the energy consumption of more
> programs is made available (via badges?), it may be beneficial to have
> an easy and consistent way for users to find the relevant information.

Fair enough.

I don't see how to make it fit in the About dialog though. The About dialog is 
not very customizable (on purpose, so that all apps show the same).

One option is to add it as "Other" text, but IMHO it's a bit too prominent, 
before the copyright and okular webpage link 
https://i.imgur.com/ZkRIoTr.png

The other option is have it in the "Thanks" section, which is semantically 
wrong (e.g. the web link tooltip says "Visit the contributors page") 
https://i.imgur.com/VbkajK2.png

Maybe we should just go for the manual?

Cheers,
  Albert

> Cheers,
> Joseph

Re: Blue Angel info | include in manual or "About" info-box?

[Joseph P. De Veaugh-Geiss]

Hi!

On 12/2/22 00:05, Albert Astals Cid wrote:

I'm not against it, but what's the actual benefit of having that mention?

I can see it's appeal on the webpage, it tells people we're serious, a good
app, etc etc so it's a "selling point"

But on the manual/about box, the person is already using the app, so they
don't need to be sold on it.


I can see at least two reasons to include it there:

- Many users may be using Okular and not know it has been eco-certified. 
This would be a way to inform them about certification if they do not go 
to the main website.


- As more KDE aps are certified or the energy consumption of more 
programs is made available (via badges?), it may be beneficial to have 
an easy and consistent way for users to find the relevant information.


Cheers,
Joseph

--
Joseph P. De Veaugh-Geiss
BE4FOSS Project and Community Manager (KDE Eco)
OpenPGP: 8FC5 4178 DC44 AD55 08E7 DF57 453E 5746 59A6 C06F

Re: Help Navigating Source Code

[Albert Astals Cid]

El dijous, 1 de desembre de 2022, a les 18:35:49 (CET), Hank Greenburg va 
escriure:
> Hello,
> I am looking at contributing to Okular but am having a hard time navigating
> the source code. I was wondering if anyone could point me in the direction
> of the code for the highlighters, and popup notes?

What do you mean "the code for the highlighters, and popup notes"?

The UI dialogs? the toolbar? how UI to add them? How they are painted on page?

> Also, is there a Matrix chat room for Okular 

https://matrix.to/#/#okular:kde.org

> or is the mailing list the only place to ask this question or any other 
questions one might have?

Though it's possible the mailing list will give you more answers (please 
subscribe)

Cheers,
  Albert

> 
> Thank you for your time!

Re: Blue Angel info | include in manual or "About" info-box?

[Albert Astals Cid]

El dimarts, 29 de novembre de 2022, a les 16:23:28 (CET), Joseph P. De Veaugh-
Geiss va escriure:
> Hello,
> 
> I was talking with Cornelius and we thought it might be worth including
> information about Okular receiving the Blue Angel in Okular's manual or
> the "About" info-box in the application itself. (I looked but didn't
> find one, though.)
> 
> Would this be something Okular developers would be interested in?

I'm not against it, but what's the actual benefit of having that mention?

I can see it's appeal on the webpage, it tells people we're serious, a good 
app, etc etc so it's a "selling point"

But on the manual/about box, the person is already using the app, so they 
don't need to be sold on it.

Cheers,
  Albert

> 
> I have prepared two texts that may be used for this; see below.
> 
> If you agree this is a good idea, please let me know if I can help in
> any way.
> 
> Cheers,
> Joseph
> 
> == short text ==
> 
> In February 2022, Okular was awarded the Blue Angel environmental label
> award by the German government for sustainable software design.
> 
> == long text ==
> 
> In February 2022, Okular was awarded the Blue Angel environmental label
> award by the German government for sustainable software design. To
> obtain the ecolabel, Okular demonstrated it meets a list of requirements
> considered critical for the environment over the product's life cycle.
> These included transparency in energy and resource consumption when
> using Okular and the ability to run the application on hardware at least
> five years old, as well as compliance with a list of user autonomy
> requirements which reduce the environmental impact of software.

Re: Blue Angel info | include in manual or "About" info-box?

[Joseph P. De Veaugh-Geiss]

Hi,

On 11/29/22 17:53, Ingo Klöcker wrote:

I like this idea. "About Okular" is in the Help menu and the manual can also
be opened from the Help menu.


Excellent!


Alternatively to adding some text to the About dialog, we could (could we?)
add the Blue Angel certification logo and link it to some page giving details
(e.g. the manual).


With respect to the guidelines of the Blue Angel, adding the following 
logo is permitted:


  https://okular.kde.org/images/rees-en.svg

There is also this site with information to link to:

  https://www.blauer-engel.de/en/products/kde-okular

Cheers,
Joseph

--
Joseph P. De Veaugh-Geiss
BE4FOSS Project and Community Manager (KDE Eco)
OpenPGP: 8FC5 4178 DC44 AD55 08E7 DF57 453E 5746 59A6 C06F

---
KDE Eco: Building Energy-Efficient Free Software!

Website: https://eco.kde.org
Mastodon: @be4foss@floss.social
Mailing list: 
https://mail.kde.org/cgi-bin/mailman/listinfo/energy-efficiency

Matrix: https://webchat.kde.org/#/room/#energy-efficiency:kde.org
Forum: https://forum.kde.org/viewforum.php?f=334

Re: Blue Angel info | include in manual or "About" info-box?

[Ingo Klöcker]

On Dienstag, 29. November 2022 16:23:28 CET Joseph P. De Veaugh-Geiss wrote:
> I was talking with Cornelius and we thought it might be worth including
> information about Okular receiving the Blue Angel in Okular's manual or
> the "About" info-box in the application itself. (I looked but didn't
> find one, though.)

I like this idea. "About Okular" is in the Help menu and the manual can also 
be opened from the Help menu.

Alternatively to adding some text to the About dialog, we could (could we?) 
add the Blue Angel certification logo and link it to some page giving details 
(e.g. the manual).

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.

[okular] [Bug 402397] Okular crashes while trying to re-open already deleted document at startup

[Bug Janitor Service]

https://bugs.kde.org/show_bug.cgi?id=402397

Bug Janitor Service  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |WORKSFORME
 Status|NEEDSINFO   |RESOLVED

--- Comment #4 from Bug Janitor Service  ---
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 402397] Okular crashes while trying to re-open already deleted document at startup

[Bug Janitor Service]

https://bugs.kde.org/show_bug.cgi?id=402397

--- Comment #3 from Bug Janitor Service  ---
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: [okular] [Bug 458723] PDF document isn't shown - "Please wait ..." message is shown instead

[Ingo Klöcker]

On Mittwoch, 19. Oktober 2022 23:43:47 CEST Albert Astals Cid wrote:
> --- Comment #10 from Albert Astals Cid  ---
> (In reply to johnathan from comment #9)
> 
> > so now firefox can edit xfa forms, allow users to type in a name or tick a
> > checkbox but okular cannot even display the file?  yeah

Toxic bug reports like this one made me stop reading bug reports for kmail to 
protect my mental health.

> Firefox has a like 700 employees, Okular has 0. I don't see why it is
> surprising to you. Also XFA is basically a webpage so adding support for it
> in Firefox is defenitely easier than in Okular.
> 
> But yes please be an asshole to us developers, that will for sure make us
> work for free for ungrateful people like you

You could have worded it a bit more politely. Or, even better, you could have 
ignored it. I know from own experience that ignoring such reports is hard, but 
I think it's the best option for everyone. Simply delete such toxic bug report 
emails and try to forget about them. You have no obligation to justify the 
decisions and actions of the Okular team (or any other Free Software team) to 
anybody.

Take care, Albert and all other KDE contributors! ❤️

Regards,
Ingo

signature.asc
Description: This is a digitally signed message part.

Re: [okular] [Bug 459333] Errors with media files

[Albert Astals Cid]

El dimecres, 12 d’octubre de 2022, a les 16:15:37 (CEST), Ingo Klöcker va 
escriure:
> On Montag, 19. September 2022 19:23:44 CEST Ingo Klöcker wrote:
> > The Craft recipe for Okular includes phonon, but no backend. KStars
> > includes phonon-vlc (to be able to play .ogg notification files). After
> > copying the simpleplayer demo of phonon to the bin folder of KStars I
> > could play the sound of a video with simpleplayer, but the video display
> > stayed black. Maybe the video codec is missing.
> > 
> > So, the first thing to do would be to add phonon-vlc as dependency of
> > okular in craft.
> 
> I have now added phonon-vlc as dependency of okular in the craft blueprint.
> 
> Do you have some test PDFs with embedded multimedia files that I could test
> the next Windows build of okular with?

I'd say ask the reporter in https://bugs.kde.org/show_bug.cgi?id=459333

If you make the ones i have but not theirs it's not great for them :D

Cheers,
  Albert

> 
> Regards,
> Ingo

Re: [okular] [Bug 459333] Errors with media files

[Ingo Klöcker]

On Montag, 19. September 2022 19:23:44 CEST Ingo Klöcker wrote:
> The Craft recipe for Okular includes phonon, but no backend. KStars includes
> phonon-vlc (to be able to play .ogg notification files). After copying the
> simpleplayer demo of phonon to the bin folder of KStars I could play the
> sound of a video with simpleplayer, but the video display stayed black.
> Maybe the video codec is missing.
> 
> So, the first thing to do would be to add phonon-vlc as dependency of okular
> in craft.

I have now added phonon-vlc as dependency of okular in the craft blueprint.

Do you have some test PDFs with embedded multimedia files that I could test the 
next Windows build of okular with?

Regards,
Ingo

signature.asc
Description: This is a digitally signed message part.

[okular] [Bug 402397] Okular crashes while trying to re-open already deleted document at startup

[Justin Zobel]

https://bugs.kde.org/show_bug.cgi?id=402397

Justin Zobel  changed:

   What|Removed |Added

 Resolution|--- |WAITINGFORINFO
 Status|REPORTED|NEEDSINFO

--- Comment #2 from Justin Zobel  ---
Thank you for reporting this crash in KDE software. As it has been a while
since this issue was reported, can we please ask you to see if you can
reproduce the crash with a recent software version?

If you can reproduce the issue, please change the status to "CONFIRMED" when
replying. Thank you!

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: [okular] [Bug 459333] Errors with media files

[Ingo Klöcker]

On Sonntag, 18. September 2022 19:19:00 CEST you wrote:
> https://bugs.kde.org/show_bug.cgi?id=459333
> 
> Albert Astals Cid  changed:
> 
>What|Removed |Added
> 
> CC||aa...@kde.org,
>||kloec...@kde.org
> 
> --- Comment #1 from Albert Astals Cid  ---
> Ingo would you please try to figure out if Phonon has support for Windows
> nowadays?

The Craft recipe for Okular includes phonon, but no backend. KStars includes 
phonon-vlc (to be able to play .ogg notification files). After copying the 
simpleplayer demo of phonon to the bin folder of KStars I could play the sound 
of a video with simpleplayer, but the video display stayed black. Maybe the 
video codec is missing.

So, the first thing to do would be to add phonon-vlc as dependency of okular in 
craft. Or some other backend. There seems to be an outdated phonon-ds9 (for 
DirectShow), but it does already fail at cmake.

There doesn't seem to be a Craft recipe for gstreamer and therefore also none 
for phonon-gstreamer.

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.

Re: [okular] [Bug 458516] Spaces in content filenames causes a second copy of the book's content to be shown; TOC points to the second copy.

[duane-tech]

On 2022-09-13 15:57, Albert Astals Cid wrote:

https://bugs.kde.org/show_bug.cgi?id=458516

--- Comment #3 from Albert Astals Cid  ---
I don't see any problem with the attached file.

What is wrong with it?

The file itself is OK. The problem is in Okular's displaying of the 
file. I've added a screenshot of Okular illustrating the problem to the 
bug report [ https://bugsfiles.kde.org/attachment.cgi?id=152038 ].


Note that the TOC shows chapters 1-3 pointing to pages 4-6. This is the 
second copy of the content. The first copy of chapters 1-3 is on pages 
1-3. Page through the document and you'll see it displayed as:

page 1  Chapter 1
page 2  Chapter 2
page 3  Chapter 3
page 4  Chapter 1 (pointed to by TOC)
page 5  Chapter 2 (pointed to by TOC)
page 6  Chapter 3 (pointed to by TOC)
page 7  (blank)

Yet, the epub contains only (chapter) files:
te st_split_000.html
te st_split_001.html
te st_split_002.html

Rename the epub files to "test_split_000.html", "test_split_001.html", 
and "test_split_002.html", and edit "content.opf" and "toc.ncx" to 
contain the new names and Okular stops displaying the first copy of the 
chapters. Pages in the TOC are corrected as well.

Re: Hi, I'm the App Stores Support Engineer guy

[Albert Astals Cid]

El dimecres, 7 de setembre de 2022, a les 11:12:46 (CEST), Ingo Klöcker va 
escriure:
> Hi Okular people,

Hello :)

> 
> as you may have read on the community mailing list [1], I'm taking on the
> role of App Stores Support Engineer for KDE.
> 
> Aleix Pol wrote:
> "Ingo will be working with the different teams in KDE towards our
> infrastructure getting prepared to have their software delivered to
> the platforms they are targetting. With this, we hope to improve the
> reach of our products to end users and hopefully enable them also to
> make a living with their KDE products."
> 
> You do already publish Okular in the Windows Store and it has got a few nice
> reviews. That's great!
> 
> Here are a few questions I'm interested in:
> 
> a) Where can I find more information about your building and publishing
> process? Who should I talk to in your team?

For Windows

It's build by binary-factory via Craft. The publishing process is the same as 
the rest of KDE Windows Store app, done via the webui. After putting it there 
you also but the corresponding exe in 
  https://download.kde.org/stable/release-service/x.y.x/windows/
i.e.
  https://download.kde.org/stable/release-service/22.08.0/windows/
for posterity.

Nico Fella and me have been the ones doing the updates lately.

For Android i don't really remember what i did last time, but as far as i 
remember same-ish, get the build from the binary factory, upload it to the 
android web ui.

Of course some testing applies before uploading ;)

> b) Are there things you wish the KDE infrastructure would better support
> with regard to building for different platforms and publishing in different
> app stores?
> 
> c) Are there things in the KDE Frameworks that should be improved to ease
> building for different platforms, e.g. do you patch some KDE Frameworks when
> you create builds for Windows or macOS?

There's no patches in Craft for KF5 as far as i know.

One of the Craft blueprints shortcomings is that it does not use the KDE Qt5 
Patch collection

> d) Do you want to target more platforms and/or app stores? If yes, which and
> in which order?

Getting this fixed wouldn't hurt i guess 
https://binary-factory.kde.org/job/Okular_Nightly_macos/

My guess is that Windows should be one of the main focuses, there must be a 
sizeable chunk of users out there because when we break something (we broke 
saving in 22.08.0) we get bug reports in bugs.kde.org which is somewhat alien 
for a regular windows user i'd say :D

> 
> e) Are there tasks/issues on some task board or issue tracker that I should
> look at?

I don't think there's any particular task other than the bugs in 
https://bugs.kde.org/

Main thing i can think of being broken on Windows that would be nice to fix is 
that tabs don't work because one needs dbus for that which we don't ship/have 
on Windows. I think kate fixed it by using some other framework instead of 
dbus.

> 
> f) Is this mailing list the right place to talk about this?

Sure :)

Cheers,
  Albert

> 
> Regards,
> Ingo
> 
> [1] https://mail.kde.org/pipermail/kde-community/2022q3/007274.html

Re: user interface for attach & detach

[Andreas Naumann]

Am 04.05.22 um 00:48 schrieb Albert Astals Cid:

El dissabte, 30 d’abril de 2022, a les 21:28:09 (CEST), Andreas Naumann va 
escriure:

I am working on the detach and re-attach of a tab in okular.

The current implementation in MR 616
(https://invent.kde.org/graphics/okular/-/merge_requests/616) allows to
detach a tab into a new okular instance. If tabs are enabled, an
existing tab can be moved to another instance.

However, if exactly one file is open, then we do not see the tab bar,
but only one window. That raises the question, how can a user move that
instance/file to another instance?

Until now I have the following workflows / user interfaces in mind:

(1) Drag the window (at the title) with the single file above another
instance: From my perspective, this feels most intuitive.
(2) Drag the "page" (click with the mouse somewhere next to the text)
and move into another window: This feels also intuitive, but is in
conflict with the page movement of a zoomed page.
(3) Insert some button/icon in the toolbar: How should that button
look like and intuitively like "attach some where else".
(4) Use a shortcut, to show other okular instances in a dialog: That
feels less intuitive. In particular, it is inconsistent with the
detaching from a multi-tab.

I implemented the interface (1), but have some trouble with Qt. The
basic idea was to overload the member function "Shell::moveEvent", check
if the main window was moved on top of another okular window and if so,
than open the file in the other instance and close the single-file-window.
This approach has one big drawback: the function moveEvent is also
called, when the new window starts. Thus, if one detaches, or creates a
new okular instance, which (by possibility or accident) starts above
another window, it will be closed and attached to that.

Finally I have two questions:

1. Which interface/workflow would you prefer?

Alternative suggestion:
  * Add a sub-option to "Always show tabs" [even if there's only one document 
open] in the configuration. It's what konsole and firefox do. And then people that like 
dragging tabs around can enable that and be happy dragging the tags.

What do you think?


That is the way, I implemented the feature now. If the option "Keep tab"
is enabled, we keep the tab box even if there is only one open file.

The user interface works two fold now:
  1. simple drag and drop: If the mouse leaves the window, a "drag"
action is started. Thus a user can simply drop the file in any other
application (which supports drag'n drop). This is like a "copy
operation". Even if you drop the file onto another okular instance, we
keep it open at the source.
  2. drag while pressing "shift". That detaches the file from the
current okular instance and removes. This is like a "move operation". I
chose the shift key, because it is similar to the behavior of dolphin.
There "shift & drag" means move the file to the destination.

Regards,
Andreas



Cheers,
   Albert


2. Do you have any other suggestion for the implementation of (1)?

All best,
Andreas

Re: Okular | statistics before and after BE eco-certification

[Albert Astals Cid]

El dilluns, 20 de juny de 2022, a les 17:28:06 (CEST), Joseph P. De Veaugh-
Geiss va escriure:
> Hi!
> 
> I would be interested in Okular statistics before and after receiving
> the Blue Angel eco-label. [1]
> 
> Would it be possible to obtain data for 2022 related to website (Matomo)

I sent you on Matrix a capture of the visits for the MS Store, it's mostly 
static except a 4x/5x increase in 7/8 of May.

> or download statistics (e.g., Ubuntu, Microsoft Store)?

I've no idea how to access Snap store downloads, ask JRiddell maybe?

I sent you on Matrix a capture of the downloads for the MS Store, it's mostly 
lineal.

> 
> FYI In the near future I plan to go through Debian's popularity contest
> data for Okular: https://qa.debian.org/popcon.php?package=okular
> 
> Are there other statistics you think I should take a look at?

https://pkgstats.archlinux.de/packages/okular ?

Cheers,
  Albert

> 
> Cheers,
> Joseph
> 
> [1] https://eco.kde.org/blog/2022-03-16-press-release-okular-blue-angel/

RE: [okular] [Bug 455650] New: Garbage Printing for PDF with form data

[andreas-naumann]

I can confirm the problem. Even the empty form shows a different spacing 
between the printed and the displayed file.If it helps, the problem is also 
visible in the print preview.Von meinem/meiner Galaxy gesendet

Re: Please fix one thing about Okular ..

[Oliver Sander]

Hi John-Albert,

for me, highlighting only goes off if I *right*-click
in the document.  Left- and middle-clicks keep the highlighter
selected.

Do you happen to use a fairly old version of Okular?
The annotation GUI got a big rewrite a while ago.
Please get a recent version of Okular and try that.

Best regards,
Oliver


On 13.05.22 03:49, John-Albert Eadie wrote:

Long time since I developed anything but I *love*
Okular for yellow highlighting and saving .pdfs of
research.  However for me there is one BIG PROBLEM ...

If I click on the document in any way *including the
right mouse button*, highlighting goes off and I have
to go up and choose Yellow Highlighter again.  Very
annoying.  Because I'm slighty shaky, it happens
many times during my edit.

I recommend switching off the Yellow Highlighter
only when left mouse click happens, not any
mouse click turning it off.  Even better,
only left mouse click on Yellow
Highlighter itself.

Please.  Thanks,

-jae

Ps: I am a million miles (50 years) away from
     coding but would it be possible to compile a
     version of my own?  How massive?

     Thanks again.
--

¯\_(ツ)_/¯

*both.and.e...@gmail.com*

  ‘King of Spaghetti Code’




smime.p7s
Description: S/MIME Cryptographic Signature

Re: user interface for attach & detach

[Albert Astals Cid]

El dissabte, 30 d’abril de 2022, a les 21:28:09 (CEST), Andreas Naumann va 
escriure:
> I am working on the detach and re-attach of a tab in okular.
> 
> The current implementation in MR 616
> (https://invent.kde.org/graphics/okular/-/merge_requests/616) allows to
> detach a tab into a new okular instance. If tabs are enabled, an
> existing tab can be moved to another instance.
> 
> However, if exactly one file is open, then we do not see the tab bar,
> but only one window. That raises the question, how can a user move that
> instance/file to another instance?
> 
> Until now I have the following workflows / user interfaces in mind:
> 
>(1) Drag the window (at the title) with the single file above another
> instance: From my perspective, this feels most intuitive.
>(2) Drag the "page" (click with the mouse somewhere next to the text)
> and move into another window: This feels also intuitive, but is in
> conflict with the page movement of a zoomed page.
>(3) Insert some button/icon in the toolbar: How should that button
> look like and intuitively like "attach some where else".
>(4) Use a shortcut, to show other okular instances in a dialog: That
> feels less intuitive. In particular, it is inconsistent with the
> detaching from a multi-tab.
> 
> I implemented the interface (1), but have some trouble with Qt. The
> basic idea was to overload the member function "Shell::moveEvent", check
> if the main window was moved on top of another okular window and if so,
> than open the file in the other instance and close the single-file-window.
> This approach has one big drawback: the function moveEvent is also
> called, when the new window starts. Thus, if one detaches, or creates a
> new okular instance, which (by possibility or accident) starts above
> another window, it will be closed and attached to that.
> 
> Finally I have two questions:
> 
> 1. Which interface/workflow would you prefer?

Alternative suggestion: 
 * Add a sub-option to "Always show tabs" [even if there's only one document 
open] in the configuration. It's what konsole and firefox do. And then people 
that like dragging tabs around can enable that and be happy dragging the tags.

What do you think?

Cheers,
  Albert

> 
> 2. Do you have any other suggestion for the implementation of (1)?
> 
> All best,
> Andreas
> 
> 
> 

RE: [okular] [Bug 431506] Quick access to change paper color

[andreas-naumann]

To   me, this reads like a change in the theme. So in the night you would have 
a dark theme, where okular adapts the colors accordingly. I think kde provides 
such a feature. Does okular adhere to it? Von meinem/meiner Galaxy gesendet

Re: Press Release: Okular, world's first eco-certified software product!

[Jos van den Oever]

Congratulations Okular!

Is the actual certificate available? I'd like to know what criteria are 
part of Blauer Engel and how Okular scores on them. If this is easy to 
find, other projects could know how to improve their software too. Did 
certification lead to additions the the CI?


Best regards,
Jos

Joseph P. De Veaugh-Geiss schreef op 2022-03-16 10:23:


Apologies for cross-posting!

[Deutsch unten]

Today KDE is excited to announce that Okular, the multi-platform 
universal document viewer, is the first ever eco-certified computer 
program!


*First Ever Eco-Certified Computer Program: KDE's Popular PDF Reader 
Okular*


The multi-platform Free and Open-Source Software product is now 
officially recognized for sustainable software design


https://eco.kde.org/blog/2022-03-16-press-release-okular-blue-angel/

/Summary/: Okular, KDE's popular multi-platform PDF reader and 
universal document viewer, has officially been recognized for 
sustainable software design. In February 2022 Okular was awarded the 
Blue Angel ecolabel, the official environmental label awarded by the 
German government. Introduced in 1978, Blue Angel is the world's 
earliest-established environmental label, and Okular is the first 
software product ever to be certified with its seal. What is more, 
Okular is the first ️ever eco-certified computer program within the 30 
organizations of the Global Ecolabelling Network!


Released under the GPLv2+ license, Okular is Free and Open-Source 
Software, and so it was also already fulfilling many of the user 
autonomy criteria necessary to obtain the Blue Angel seal of approval. 
Further work was carried out to make Okular fully compliant with all of 
the Blue Angel criteria, and become officially recognized as providing 
transparency in energy and resource consumption, extending the 
potential hardware operating life of devices, and enabling user 
autonomy.


Today we are celebrating the achievement together with the wider Free 
Software community [1], as well as with the computer science department 
at Umwelt Campus Birkenfeld [2], where researchers measured the 
resource and energy-consumption of Okular and other KDE software.


KDE and the Free Software community would like to send a heartfelt 
thank you to the Okular developers for making environmentally-friendly 
software for all of us!


Mastodon toot: https://mastodon.social/web/@BE4FOSS/107965444323062309

Best wishes,
Joseph P. De Veaugh-Geiss

[1] https://fsfe.org/news/2022/news-20220316-01.en.html
[2] 
https://www.umwelt-campus.de/en/forschung/projekte/green-software-engineering/news-details/first-blue-angel-for-software


== Deutsche Version ==

KDE freut sich, heute ankündigen zu können, dass Okular, der 
plattformübergreifende universelle Dokumenten-Viewer, das erste 
öko-zertifizierte Computerprogramm überhaupt ist!


Pressemitteilung: 16. März 2022

*Erstes öko-zertifiziertes Computerprogramm überhaupt: KDEs beliebter 
PDF-Reader Okular*


Das plattformübergreifende Freie- und Open-Source-Software-Produkt ist 
nun offiziell für nachhaltiges Software-Design anerkannt


https://eco.kde.org/blog/2022-03-16-press-release-okular-blue-angel/

/Zusammenfassung/: Okular, KDEs beliebter plattformübergreifender 
PDF-Reader und universeller Dokumenten-Viewer, ist offiziell für 
nachhaltiges Softwaredesign ausgezeichnet worden. Im Februar 2022 wurde 
Okular mit dem Umweltzeichen Blauer Engel ausgezeichnet, dem 
offiziellen Umweltzeichen der deutschen Bundesregierung. Der Blaue 
Engel wurde 1978 eingeführt und ist das älteste Umweltzeichen der Welt. 
Okular ist das erste Softwareprodukt, das mit diesem Siegel 
zertifiziert wurde. Darüber hinaus ist Okular das erste jemals 
öko-zertifizierte Computerprogramm innerhalb der 30 Organisationen des 
Global Ecolabelling Network!


Okular wurde unter der GPLv2+-Lizenz veröffentlicht, ist also eine 
freie und quelloffene Software und erfüllte somit bereits viele der 
Kriterien der Benutzerautonomie, die für die Verleihung des Blauen 
Engels erforderlich sind. Es wurde weiter daran gearbeitet, dass Okular 
alle Kriterien des Blauen Engels erfüllt und offiziell anerkannt wird, 
da es Transparenz beim Energie- und Ressourcenverbrauch bietet, die 
potenzielle Hardware-Lebensdauer von Geräten verlängert und die 
Autonomie der Nutzer*innen ermöglicht.


Heute feiern wir diese Erfolge gemeinsam mit der Free Software 
Foundation Europe [1] sowie mit der Informatikabteilung des 
Umwelt-Campus Birkenfeld [2], wo Forscher*innen den Ressourcen- und 
Energieverbrauch von Okular und anderer KDE-Software gemessen haben.


KDE und die Freie-Software-Community möchten den Okular-Entwicklern ein 
herzliches Dankeschön dafür aussprechen, dass sie umweltfreundliche 
Software für uns alle entwickelt haben!


Mastodon toot: https://mastodon.social/web/@BE4FOSS/107965444323062309

[1] https://fsfe.org/news/2022/news-20220316-01.en.html
[2] 

Re: press release feedback | "First Ever Eco-Certified Computer Program: KDE's Popular PDF-Reader Okular"

[Albert Astals Cid]

El dimarts, 8 de març de 2022, a les 12:31:31 (CET), David Hurka va escriure:
> I think it is also important that users have the choice which program to use. 
> There are other programs which may be candidates for the same eco label. 
> Maybe 
> link to https://pdfreaders.org?
> 
> (My favourite example for such other programs is Atril, although its not 
> listed on that page.)

I don't think that doesn't make any sense, you don't write a Press Release 
saying "use other software too if you want".

There's being nice, which I'm all for, and there's being unnecessarily nice.

We (greater we, I did nothing) did the work, we are the "First Ever 
Eco-Certified Computer Program", let's not diminish that by saying "others 
could maybe get the label too", sure they probably *could*, but have they? no, 
they haven't.

Cheers,
  Albert

Re: Feature Request: make annotation stuck

[Gordon Shawn]

Yes it's a snap install on ubuntu 20.04, which is the only approach unless
I compile from source.

On Mon, Mar 7, 2022 at 8:50 AM David Hurka  wrote:

> Hi Gordon,
>
> > I was using Okular on ubuntu 20.04 which is version 1.9.3 [...]
> >
> > I could not switch to the new Okular because another key feature was
> > missing: General Options --> Open new files in tabs.
> > [...]
> > It's probably already reported as a bug
> > at https://bugs.kde.org/show_bug.cgi?id=434777
>
> That bug is about Okular being installed as snap/flatpak.
> It makes some sense that snap/flatpak breaks this feature.
>
> So I understand that your Ubuntu based distribution does not ship a newer
> Okular, so you tried to install a newer version via snap or flatpak?
>
> Otherwise, if you observed the feature to work in older versions with snap/
> flatpak, that would be an interesting information, which you may add to
> the
> bug report.
>
>
>

Re: Do we want to force braces even for 1 line if/for/etc?

[Albert Astals Cid]

El diumenge, 6 de març de 2022, a les 8:07:08 (CET), Simone Gaiarin va escriure:
> Yes, let's do that.

Ok, I'll commit on thursday unless somoene strongly disagrees.

Cheers,
  Albert

> 
> 
> 
> 
> On Thu, Mar 3, 2022 at 11:42 PM Albert Astals Cid  wrote:
> 
> > El divendres, 6 de novembre de 2020, a les 0:27:05 (CET), Albert Astals
> > Cid va escriure:
> > > El divendres, 11 de setembre de 2020, a les 22:00:30 CET, Albert Astals
> > Cid va escriure:
> > > > El divendres, 21 d’agost de 2020, a les 1:19:19 CEST, Albert Astals
> > Cid va escriure:
> > > > > Most of the guidelines suggest it so that you don't forget to add
> > them when adding a new line in the "block".
> > > > >
> > > > > What do you think?
> > > > >
> > > > > https://invent.kde.org/graphics/okular/-/merge_requests/248
> > > > >
> > > > > We're going to need quite some changes to make it pass, so asking
> > before starting to do the work :D
> > > >
> > > > We agreed on the Akademy Okular meeting that we will do this, *but*
> > I'm going to postpone doing it after the 20.08.3 release.
> > > >
> > > > Rationale:
> > > >  * Making this change even if mechanical (clang-tidy does it) can
> > cause potential regressions if something goes wrong, hence is something
> > that needs to be applied in master only
> > > >  * If we apply it to master now, merging up from release/20.08 to
> > master can cause master CI to stop compiling since it'd be requiring more
> > things than release/20.08 CI
> > >
> > > Going to postpone this because it seems not clang-tidy 10 nor 11 nor 12
> > are able to format Okular codebase correctly with
> > readability-braces-around-statements
> >
> > clang-tidy-13 seems to have succeeded.
> >
> > What do you say, should we give it a go?
> >
> > https://invent.kde.org/graphics/okular/-/merge_requests/578
> >
> > Cheers,
> >   Albert
> >
> > >
> > > Cheers,
> > >   Albert
> > >
> > > >
> > > > Cheers,
> > > >   Albert
> > > >
> > > > >
> > > > > Cheers,
> > > > >   Albert
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> 

Re: Feature Request: make annotation stuck

[andreas-naumann]

As far als i remember, you can enable  tabs in the settings.

Re: Feature Request: make annotation stuck

[Gordon Shawn]

Thanks. Yes that indeed works in the newest Okular. I was using Okular on
ubuntu 20.04 which is version 1.9.3 and does not have that feature. Thank
you for pointing it out.

I could not switch to the new Okular because another key feature was
missing: General Options --> Open new files in tabs. I tried this about 1
year ago and just tried it again. Any new PDF will open a new Okular
window(instead of tab) when I click in my file manager. The tab only works
when I choose File-Open. In old Okular, I can open a PDF from anywhere
externally and they will be put into tabs under one Okular. It's probably
already reported as a bug at https://bugs.kde.org/show_bug.cgi?id=434777

In my opinion this is a real bug, we all have multiple PDFs open at the
same time, and nobody wants to have multiple windows laying around. All
other PDF viewers can do tabs well, and this feature is just essential.

Gordon

From: Simone Gaiarin 
To: Okular development 
Subject: Re: Feature Request: make annotation stuck
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hi Gordon,
the feature you are requesting already exists.

To activate it:
1. Show the annotation toolbar by selecting Settings > Annotations
2. Click on the "pin" icon with the tooltip "Keep the annotation tool
active after use"

Bye




On Sat, Mar 5, 2022 at 4:10 PM Gordon Shawn  wrote:

> When I need do annotations most of the time I repeat the same action(e.g
> highlight it), for that I need  to move cursor to click the highlight
> button each time, can we have an option to make the annotation selection
> stuck? so I can keep doing the same thing(e.g. highlighting) until I click
> the annotation tools to unselect. This will save quick some mouse clicks.
>
> Thanks for your consideration,
>
> Gordon

Re: Feature Request: Improve usability of Reviews--Highlight

[Simone Gaiarin]

Hi Gordon,
I agree that there is space for improvement in the annotations sidebar.

At the moment, you can use the two buttons at the bottom left of the
annotations sidebar that allows you to hide the pages and authors. In this
way to navigate the annotations you can use Up/Down arrow + Enter. Moreover
there are two other buttons at the bottom right to collapse/expand all the
pages/authors.

Bye



On Sat, Mar 5, 2022 at 4:11 PM Gordon Shawn  wrote:

> I make a lot of highlights in PDF, Okular is irreplaceable on Linux due to
> its great annotation tools for PDFs. Thanks for making it!
>
> When I review  the highlighted areas, I need to click on Reviews, then
> Page, then username, then pick one highlight from a list of them. That's 4
> clicks to see one highlighted area.
>
> Can we have a button to do "next/prev highlight"?
>
> Even better, since one page can have multiple highlighted areas, and our
> screen normally display the whole page at a time, it will be even better if
> we can do prev/next for highlighted pages.
>
> Enhancing annotation and review UX will make Okular even more great,
> they're the best features of Okular in my opinion.
>
> Thanks,
> Gordon
>

Re: Do we want to force braces even for 1 line if/for/etc?

[Simone Gaiarin]

Yes, let's do that.




On Thu, Mar 3, 2022 at 11:42 PM Albert Astals Cid  wrote:

> El divendres, 6 de novembre de 2020, a les 0:27:05 (CET), Albert Astals
> Cid va escriure:
> > El divendres, 11 de setembre de 2020, a les 22:00:30 CET, Albert Astals
> Cid va escriure:
> > > El divendres, 21 d’agost de 2020, a les 1:19:19 CEST, Albert Astals
> Cid va escriure:
> > > > Most of the guidelines suggest it so that you don't forget to add
> them when adding a new line in the "block".
> > > >
> > > > What do you think?
> > > >
> > > > https://invent.kde.org/graphics/okular/-/merge_requests/248
> > > >
> > > > We're going to need quite some changes to make it pass, so asking
> before starting to do the work :D
> > >
> > > We agreed on the Akademy Okular meeting that we will do this, *but*
> I'm going to postpone doing it after the 20.08.3 release.
> > >
> > > Rationale:
> > >  * Making this change even if mechanical (clang-tidy does it) can
> cause potential regressions if something goes wrong, hence is something
> that needs to be applied in master only
> > >  * If we apply it to master now, merging up from release/20.08 to
> master can cause master CI to stop compiling since it'd be requiring more
> things than release/20.08 CI
> >
> > Going to postpone this because it seems not clang-tidy 10 nor 11 nor 12
> are able to format Okular codebase correctly with
> readability-braces-around-statements
>
> clang-tidy-13 seems to have succeeded.
>
> What do you say, should we give it a go?
>
> https://invent.kde.org/graphics/okular/-/merge_requests/578
>
> Cheers,
>   Albert
>
> >
> > Cheers,
> >   Albert
> >
> > >
> > > Cheers,
> > >   Albert
> > >
> > > >
> > > > Cheers,
> > > >   Albert
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>

Re: Feature Request: make annotation stuck

[Simone Gaiarin]

Hi Gordon,
the feature you are requesting already exists.

To activate it:
1. Show the annotation toolbar by selecting Settings > Annotations
2. Click on the "pin" icon with the tooltip "Keep the annotation tool
active after use"

Bye




On Sat, Mar 5, 2022 at 4:10 PM Gordon Shawn  wrote:

> When I need do annotations most of the time I repeat the same action(e.g
> highlight it), for that I need  to move cursor to click the highlight
> button each time, can we have an option to make the annotation selection
> stuck? so I can keep doing the same thing(e.g. highlighting) until I click
> the annotation tools to unselect. This will save quick some mouse clicks.
>
> Thanks for your consideration,
>
> Gordon
>

Re: Do we want to force braces even for 1 line if/for/etc?

[Albert Astals Cid]

El divendres, 6 de novembre de 2020, a les 0:27:05 (CET), Albert Astals Cid va 
escriure:
> El divendres, 11 de setembre de 2020, a les 22:00:30 CET, Albert Astals Cid 
> va escriure:
> > El divendres, 21 d’agost de 2020, a les 1:19:19 CEST, Albert Astals Cid va 
> > escriure:
> > > Most of the guidelines suggest it so that you don't forget to add them 
> > > when adding a new line in the "block".
> > > 
> > > What do you think?
> > > 
> > > https://invent.kde.org/graphics/okular/-/merge_requests/248
> > > 
> > > We're going to need quite some changes to make it pass, so asking before 
> > > starting to do the work :D
> > 
> > We agreed on the Akademy Okular meeting that we will do this, *but* I'm 
> > going to postpone doing it after the 20.08.3 release.
> > 
> > Rationale:
> >  * Making this change even if mechanical (clang-tidy does it) can cause 
> > potential regressions if something goes wrong, hence is something that 
> > needs to be applied in master only
> >  * If we apply it to master now, merging up from release/20.08 to master 
> > can cause master CI to stop compiling since it'd be requiring more things 
> > than release/20.08 CI
> 
> Going to postpone this because it seems not clang-tidy 10 nor 11 nor 12 are 
> able to format Okular codebase correctly with 
> readability-braces-around-statements

clang-tidy-13 seems to have succeeded.

What do you say, should we give it a go?

https://invent.kde.org/graphics/okular/-/merge_requests/578

Cheers,
  Albert

> 
> Cheers,
>   Albert
> 
> > 
> > Cheers,
> >   Albert
> > 
> > > 
> > > Cheers,
> > >   Albert
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 
> 

RE: [okular] [Bug 449596] Opening PDF with Okular has application title "ISE Opener - Okular"

[andreas-naumann]

Are you sure, that you did not mixup the file pdf names?The titles given by the 
pdfs are **ISE Opener** and **Book Opener**, but in different orders than your 
report titles suggest.To me that does not look like an error in okular, but a 
mistake in the pdfs metadata.Von meinem/meiner Galaxy gesendet
 Ursprüngliche Nachricht Von: Phos  
Datum: 07.02.22  14:14  (GMT+01:00) An: okular-devel@kde.org Betreff: [okular] 
[Bug 449596] Opening PDF with Okular has application title
  "ISE Opener - Okular" https://bugs.kde.org/show_bug.cgi?id=449596--- Comment 
#4 from Phos  ---Another PDF I tested returns the 
Application Title as "Book Opener - Okular"Here's the output of pdfinfoTitle:   
    ISE OpenerSubject: Advanced Mathematical Concepts: Precalculus 
with ApplicationsAuthor:  Glencoe/McGraw-HillCreator: Adobe 
Acrobat 8.1 Combine FilesProducer:    Adobe Acrobat 8.1CreationDate:    Sat 
Nov 22 04:37:49 2008 CSTModDate: Sat Nov 22 05:02:49 2008 CSTCustom 
Metadata: noMetadata Stream: yesTagged:  noUserProperties:  noSuspects: 
   noForm:    AcroFormJavaScript:  noPages:   
1130Encrypted:   noPage size:   637.6 x 828 ptsPage rot:    0File 
size:   90256167 bytesOptimized:   noPDF version: 1.6-- You are 
receiving this mail because:You are the assignee for the bug.

Re: testing framework

[Albert Astals Cid]

El dilluns, 31 de gener de 2022, a les 0:10:07 (CET), Andreas Naumann va 
escriure:
> 
> On 30.01.22 23:21, David Hurka wrote:
> > On Sunday, January 30, 2022 1:00:01 PM CET okular-devel-requ...@kde.org 
> > wrote:
> >> Until now, I followed the instructions at
> >> https://okular.kde.org/build-it/ using kde/neon with pre-installed
> >> development libraries. My install prefix is my home folder ~/kde_installed.
> >>
> >> I am puzzled by two advices:
> >> 1) The website https://okular.kde.org/build-it/ states "If you install
> >> Okular in a different path than your system install directory it is
> >> possible that you need to run source build/prefix.sh; okular".
> >>   Does that even relate to the tests, or only to the installed
> >> binarys? That question came to my mind, because the kimgiotest loads the
> >> library "okularGenerator_kimgio.so" from the system, and the newly
> >> compiled one.
> >>   The command "source build/prefix.sh" updates the environment, but
> >> it does not change the behavior at all. It does set QT_PLUGIN_PATH to
> >> the installed path. But the test seems to ignore it.
> >> kde/neon with pre-installed development libraries.
> >> source build/prefix.sh; okular
> > Hi Andreas,
> >
> > this is the same way I did it the last time, integrated in KDevelop. So it
> > should work for you too. There must be something we do differently.
> >
> > prefix.sh should change the behavior.
> >
> >> 2) The documentation at
> >> https://community.kde.org/Get_Involved/development#Test_your_changes
> >> bases on kdesrc-build. Is that the way to go for every application?
> >> It looks a bit cumbersome.
> > It is just a possible way, but it is not required.
> >
> > I am sorry that I can not fix your issue right now. I will look soon if I 
> > did
> > something special in my build environment. Do you have more details that 
> > might
> > be relevant?
> >
> > You are not the only one who has trouble with the plugin path. :/
> 
> Thanks a lot for the reply. In the mean time, I found the reason and
> solution for the problem.
> 
> The relation between the plugins and the test "kimgiotest" depends on
> the variable QT_PLUGIN_PATH. The test is added via the line 12 in
> generators/kimgio/CMakeLists.txt
> 
>"ecm_add_test(${kimgiotest_SRCS} TEST_NAME "kimgiotest"
> LINK_LIBRARIES okularcore okularpart Qt5::Svg Qt5::Test)"
> 
> This function sets the environment variable QT_PLUGIN_PATH for the test
> to the same value, as during running cmake. Thus I resolved the problem
> by running the sequence
> 
>cmake -DCMAKE_INSTALL_PREFIX=~/kde_installed ..
>source prefix.sh
>cmake .
> 
> inside the build folder. Please note mixed run of cmake and sourcing the
> prefix.
> 
> I would like to add this information to the Readme.md in the root, and
> maybe set the QT_PLUGIN_PATH during the cmake run. This would remove the
> need to source the prefix and run cmake a second time. And it might be
> less confusing for new comers :)
> 
> What do you think?

Right, QT_PLUGIN_PATH is important before running cmake, good find!

i've never had this issue since my custom compilation script sets 
QT_PLUGIN_PATH before running cmake.

This is hopefully going to be fixed "soon" 
https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/164

I'm not super happy with having to comment that in the Readme.md but if you 
find a nice way to express/explain it, patches welcome in invent :)

Cheers,
  Albert

> 
> >
> > Cheers, David
> Greetings,
> Andreas
> >
> >
> >
> 

Re: testing framework

[Andreas Naumann]

On 30.01.22 23:33, Albert Astals Cid wrote:

El dissabte, 29 de gener de 2022, a les 13:47:48 (CET), Andreas Naumann va 
escriure:

Hey @all,

I did not yet find out, how to run the tests properly. At the moment
10/20 tests fail, even on the head of branch release/21.12. With tests,
I mean running "ctest " in the build folder.

The failing tests are:
2 - kimgiotest (Failed)
6 - documenttest (SEGFAULT)
7 - searchtest (SEGFAULT)
   10 - editannotationcontentstest (Failed)
   11 - addremoveannotationtest (Failed)
   12 - translateannotationtest (Failed)
   13 - modifyannotationpropertiestest (Failed)
   14 - editformstest (Failed)
   16 - mainshelltest (SEGFAULT)
   17 - annotationtoolbartest (SEGFAULT)

Until now, I followed the instructions at
https://okular.kde.org/build-it/ using kde/neon with pre-installed
development libraries. My install prefix is my home folder ~/kde_installed.

I am puzzled by two advices:
1) The website https://okular.kde.org/build-it/ states "If you install
Okular in a different path than your system install directory it is
possible that you need to run source build/prefix.sh; okular".
  Does that even relate to the tests, or only to the installed
binarys? That question came to my mind, because the kimgiotest loads the
library "okularGenerator_kimgio.so" from the system, and the newly
compiled one.

Yes, that relates to the tests too.


  The command "source build/prefix.sh" updates the environment, but
it does not change the behavior at all. It does set QT_PLUGIN_PATH to
the installed path. But the test seems to ignore it.

That is strange, just to make sure, you have run make install, you have sourced 
the prefix.sh file and you're running ctest in the very same terminal session 
(i.e. where the environment variables have been set), right?

Have you tried if uncommenting the LD_LIBRARY_PATH line from prefix.sh helps? 
(source the script again after changing it)


Yes, I run "source prefix.sh" and "ctest " in the same shell instance.
The interesting part is, that the export of LD_LIBRARY_PATH is commented
out in the generated "prefix.sh".

With the fixed QT_PLUGIN_PATH, the test "kimgiotest" passes.

I started to check the environment variables and the content of the
referenced folders. The root cause was the combination of
 1) an installed (and incompatible) poppler plugin. The plugin also
remained there after uninstalling okular.
 2) the missing poppler development files.
Thus I never build the poppler plugin, then tests used the plugin from
the system.

Sorry for the noise and thanks for your help.

Greetings,
Andreas




2) The documentation at
https://community.kde.org/Get_Involved/development#Test_your_changes
bases on kdesrc-build. Is that the way to go for every application? It
looks a bit cumbersome.

I've never used kdesrc-build in my almost 20 years of doing KDE stuff, you can 
use it if you want, don't use it if you don't.

Cheers,
   Albert


Regards,
Andreas

Re: testing framework

[Andreas Naumann]

On 30.01.22 23:21, David Hurka wrote:

On Sunday, January 30, 2022 1:00:01 PM CET okular-devel-requ...@kde.org wrote:

Until now, I followed the instructions at
https://okular.kde.org/build-it/ using kde/neon with pre-installed
development libraries. My install prefix is my home folder ~/kde_installed.

I am puzzled by two advices:
1) The website https://okular.kde.org/build-it/ states "If you install
Okular in a different path than your system install directory it is
possible that you need to run source build/prefix.sh; okular".
  Does that even relate to the tests, or only to the installed
binarys? That question came to my mind, because the kimgiotest loads the
library "okularGenerator_kimgio.so" from the system, and the newly
compiled one.
  The command "source build/prefix.sh" updates the environment, but
it does not change the behavior at all. It does set QT_PLUGIN_PATH to
the installed path. But the test seems to ignore it.
kde/neon with pre-installed development libraries.
source build/prefix.sh; okular

Hi Andreas,

this is the same way I did it the last time, integrated in KDevelop. So it
should work for you too. There must be something we do differently.

prefix.sh should change the behavior.


2) The documentation at
https://community.kde.org/Get_Involved/development#Test_your_changes
bases on kdesrc-build. Is that the way to go for every application?
It looks a bit cumbersome.

It is just a possible way, but it is not required.

I am sorry that I can not fix your issue right now. I will look soon if I did
something special in my build environment. Do you have more details that might
be relevant?

You are not the only one who has trouble with the plugin path. :/


Thanks a lot for the reply. In the mean time, I found the reason and
solution for the problem.

The relation between the plugins and the test "kimgiotest" depends on
the variable QT_PLUGIN_PATH. The test is added via the line 12 in
generators/kimgio/CMakeLists.txt

  "ecm_add_test(${kimgiotest_SRCS} TEST_NAME "kimgiotest"
LINK_LIBRARIES okularcore okularpart Qt5::Svg Qt5::Test)"

This function sets the environment variable QT_PLUGIN_PATH for the test
to the same value, as during running cmake. Thus I resolved the problem
by running the sequence

  cmake -DCMAKE_INSTALL_PREFIX=~/kde_installed ..
  source prefix.sh
  cmake .

inside the build folder. Please note mixed run of cmake and sourcing the
prefix.

I would like to add this information to the Readme.md in the root, and
maybe set the QT_PLUGIN_PATH during the cmake run. This would remove the
need to source the prefix and run cmake a second time. And it might be
less confusing for new comers :)

What do you think?



Cheers, David

Greetings,
Andreas

Re: testing framework

[Albert Astals Cid]

El dissabte, 29 de gener de 2022, a les 13:47:48 (CET), Andreas Naumann va 
escriure:
> Hey @all,
> 
> I did not yet find out, how to run the tests properly. At the moment
> 10/20 tests fail, even on the head of branch release/21.12. With tests,
> I mean running "ctest " in the build folder.
> 
> The failing tests are:
>2 - kimgiotest (Failed)
>6 - documenttest (SEGFAULT)
>7 - searchtest (SEGFAULT)
>   10 - editannotationcontentstest (Failed)
>   11 - addremoveannotationtest (Failed)
>   12 - translateannotationtest (Failed)
>   13 - modifyannotationpropertiestest (Failed)
>   14 - editformstest (Failed)
>   16 - mainshelltest (SEGFAULT)
>   17 - annotationtoolbartest (SEGFAULT)
> 
> Until now, I followed the instructions at
> https://okular.kde.org/build-it/ using kde/neon with pre-installed
> development libraries. My install prefix is my home folder ~/kde_installed.
> 
> I am puzzled by two advices:
> 1) The website https://okular.kde.org/build-it/ states "If you install
> Okular in a different path than your system install directory it is
> possible that you need to run source build/prefix.sh; okular".
>  Does that even relate to the tests, or only to the installed
> binarys? That question came to my mind, because the kimgiotest loads the
> library "okularGenerator_kimgio.so" from the system, and the newly
> compiled one.

Yes, that relates to the tests too.

>  The command "source build/prefix.sh" updates the environment, but
> it does not change the behavior at all. It does set QT_PLUGIN_PATH to
> the installed path. But the test seems to ignore it.

That is strange, just to make sure, you have run make install, you have sourced 
the prefix.sh file and you're running ctest in the very same terminal session 
(i.e. where the environment variables have been set), right?

Have you tried if uncommenting the LD_LIBRARY_PATH line from prefix.sh helps? 
(source the script again after changing it)

> 
> 2) The documentation at
> https://community.kde.org/Get_Involved/development#Test_your_changes
> bases on kdesrc-build. Is that the way to go for every application? It
> looks a bit cumbersome.

I've never used kdesrc-build in my almost 20 years of doing KDE stuff, you can 
use it if you want, don't use it if you don't.

Cheers,
  Albert

> 
> Regards,
> Andreas
> 
> 

Re: add a commandline flag for dynamically specifying reverse-search editor command

[Albert Astals Cid]

El dimarts, 25 de gener de 2022, a les 0:22:05 (CET), Andreas Naumann va 
escriure:
> 
> On 24.01.22 23:33, Albert Astals Cid wrote:
> > El dilluns, 24 de gener de 2022, a les 22:51:49 (CET), Andreas Naumann va 
> > escriure:
> >> Hey all okular developers,
> >>
> >> please let me first introduce my self, since i am new to the list.
> >>
> >> My name is Andreas and I am from Germany. I do have several years
> >> experience in (scientific) Softwaredevelopment with C++. Since I use the
> >> KDE desktop quite regularly, I thought, I could also give something back
> >> to the community.
> >>
> >> So, I was looking for some task, I am interested in and which also
> >> serves as a starting point to learn the code base.
> >>
> >> Thus I selected the bug263732 
> >>
> >> During studying the code and trying to fix it, I asked myself some
> >> question on the code and workflow:
> >>
> >> 1. The commandline is parsed by the commandline parser from Qt. But the
> >> arguments are passed around using a string. Everytime a function needs
> >> to check for an argument, it deserializes the string to retrieve the value.
> >>
> >> That workflow has the advantage, that it requires only a QString to pass
> >> the data to other functions.
> >> I prefer to have a data structure, which contains the arguments as fields.
> >>
> >> Is there any other disadvantage in using a struct instead of a string?
> > You can't pass a struct to an already running instance of okular.
> > Well, yes you can, serializing it, which is what we do.
> >
> >> 2. Several tests fail. Is that intended, or forgotten? I did not yet dig
> >> deeper into the codebase to understand, what the tests do.
> > Tests should all mostly pass, what failures do you get?:
> 
> ctest -j2 gives:
> 
>2 - kimgiotest (Failed)
>6 - documenttest (SEGFAULT)
>7 - searchtest (SEGFAULT)
>   10 - editannotationcontentstest (Failed)
>   11 - addremoveannotationtest (Failed)
>   12 - translateannotationtest (Failed)
>   13 - modifyannotationpropertiestest (Failed)
>   14 - editformstest (Failed)
>   16 - mainshelltest (SEGFAULT)
>   17 - annotationtoolbartest (SEGFAULT)
> 
> lsb_release -a:
> 
> Distributor ID: Neon
> Description: KDE neon Unstable Edition
> Release:20.04
> Codename:  focal
> 
> git show -s HEAD:  commit 44c86de7e415e30572d774a3ec3e90681bc8abfa (HEAD
> -> release/21.12, origin/release/21.12)
> 
> 
> I appended the test result from cmake.

"You are doing it wrong"

QWARN  : KIMGIOTest::testExifOrientation(No Exif metadata) org.kde.okular.core: 
Invalid plugin factory for 
"/usr/lib/x86_64-linux-gnu/qt5/plugins/okular/generators/okularGenerator_kimgio.so":"Die
 Bibliothek 
/usr/lib/x86_64-linux-gnu/qt5/plugins/okular/generators/okularGenerator_kimgio.so
 kann nicht geladen werden: 
(/usr/lib/x86_64-linux-gnu/qt5/plugins/okular/generators/okularGenerator_kimgio.so:
 undefined symbol: 
_ZN6Okular9Generator24freeOpaqueActionContentsERKNS_19BackendOpaqueActionE)"

Did you follow https://okular.kde.org/build-it/ carefully? Specially the source 
part?

Cheers,
  Albert

> 
> Greetings,
> Andreas
> 
> 
> >
> > Cheers,
> >Albert
> >
> >>
> >> Greetings,
> >> Andreas
> >>
> >>
> >
> >
> >
>