Package Details: masterpdfeditor 5.9.98-2

Git Clone URL: https://aur.archlinux.org/masterpdfeditor.git (read-only, click to copy)
Package Base: masterpdfeditor
Description: A complete solution for viewing, creating and editing PDF files
Upstream URL: https://code-industry.net/free-pdf-editor/
Keywords: master-pdf-editor
Licenses: custom
Submitter: farseerfc
Maintainer: pgoetz
Last Packager: pgoetz
Votes: 200
Popularity: 0.87
First Submitted: 2016-12-05 01:50 (UTC)
Last Updated: 2026-04-17 01:14 (UTC)

Pinned Comments

Alad commented on 2021-03-03 16:25 (UTC)

The next person who discusses keygens will have their account suspended indefinitely.

Latest Comments

« First ‹ Previous 1 .. 26 27 28 29 30 31 32 33 34 35 Next › Last »

Popolon commented on 2018-01-03 12:30 (UTC)

As this package use precompiled binary, it should have the extension -bin in its name : like "masterpdfeditor-bin". This avoid to install not reviewable code and potentially trojaned one without knowing.

rouelle commented on 2017-12-02 16:43 (UTC)

rouelle : I received this comment from Code-Industry (author of master-pdf-editor) for version 4.3.61 "We know about the bug, it is present in French localization only. It will be fixed for the next releases, until then you can switch to Built-in language as a workaround."

rouelle commented on 2017-11-04 00:48 (UTC)

I can open any pdf but I can't append any pdf (insert) whose name is not capitalized (i.e. *.PDF instead of *.pdf). The dialog box to open (append) a file is a gtk box (not a qt5 one) which surprise me as Master pdf editor is a qt5 app. I'm using gnome-shell 3.26.2, does it make a difference? In the append box it is impossible to change the type of file neither change from *.PDF to *.* or *.pdf. To reproduce: 1. Open a pdf (will work) 2. Menu -> Document -> Insert a document [try to open a pdf file] -- This behavior is not present using same version (4.3.61) with gnome-shell 3.20 under Ubuntu-Gnome 14.04.3 LTS.

severach commented on 2017-09-18 19:46 (UTC)

If your AUR helper (yaourt) can't handle deps inside package() then file a bug.

Scimmia commented on 2017-09-18 18:30 (UTC) (edited on 2017-09-18 18:36 (UTC) by Scimmia)

No, they are runtime only deps. No reason to move them.

nTia89 commented on 2017-09-18 18:28 (UTC)

why dependency array is inside the package function? please move the dep array outside (just before makedeps array) the package function

jfrankenau commented on 2017-09-02 08:17 (UTC)

Looking in my /usr/share/applications directory packages using an absolute path are the exception. And I don't see why the desktop file does not run the executable from the package. Only when intentionally overriding $PATH this would be changed. The advantages are simple: It's possible to specify additional environment variables (for themes etc.) and use Firejail etc.

Scimmia commented on 2017-09-02 05:14 (UTC)

I'm not sure that's an advantage. The package installs a .desktop file, it should run the executable from that package. It also appears that upstream is now shipping a .desktop file, I'll probably switch to that with the next release.

jfrankenau commented on 2017-09-01 09:08 (UTC)

Yes, that would be nice. Using $PATH allows users to overwrite/wrap the application without having to overwrite the desktop entry file in ~/.local/share/applications as well.

Scimmia commented on 2017-08-31 22:05 (UTC)

That's a possibility. I would prefer to point it to the actual program instead of letting it find the symlink, but if there are advantages to doing it that way, we can do that.

« First ‹ Previous 1 .. 26 27 28 29 30 31 32 33 34 35 Next › Last »