Xournal Activity
Brought to you by:
andreasb123,
auroux
Activity for Xournal
-
Jenny posted a comment on ticket #182
Looks like the error you're seeing is related to missing build dependencies—specifically the pkg-config tool or the pkg.m4 macro file used by autoconf. Here are a few suggestions to try: Install pkg-config – It's required for PKG_CHECK_MODULES to work. You can install it using Homebrew: bash brew install pkg-config Install autoconf and automake – They help generate the correct configure script: bash brew install autoconf automake Make sure pkg.m4 is in the right place – If it's missing, autoconf...
-
lightingnerd posted a comment on ticket #182
I would like to double-down on this request. It is a sorely needed feature to really replace paid tools. This is a frequently requested feature in Xournal++, and the developer's main argument against implementing this feature centers around incompatibility with Xournal. Considering that one of the most useful features of digital note-taking is the capacity to copy and paste lines of text from websites (where word wrapping is implemented), it becomes a huge hassle to go through and edit the body of...
-
James C. posted a comment on ticket #205
My minimal fix is here: https://github.com/xournal/xournal/pull/6 Imagining that Xournal code-fix is my current form of entertainment, and that I have some ideas about variable-sized cursors, what bug would you prefer that I was looking at?
-
Denis Auroux posted a comment on ticket #5
I don't have a great sense of how many differences there are between the github repository and that on sourceforge. I think Daniel German (dmgerman on github) is or at least was the maintainer of the github repository, and that the main divergence has been including various cleaning up / infrastructure upgrade patches of the sort you proposed that I've been too lazy and unresponsive to deal with. My impression is that the actual code is fairly similar, but I don't know whether all of my bugfixes...
-
Thank you, Denis. I've adjusted my message most of the way toward yours: https://github.com/JamesC1/xournal-01/commit/e2eb38b3257d3e8f7c6d2df57b8fe4610999d4f9 The apostrophe breaks vim syntax highlighting, so I've expanded doesn't. I don't know whether gtk2-devel implies pkgconfig in my packaging. I have not yet got around to installing it. Your Xournal is very different from the one that I started with. This change: https://github.com/xournal/xournal/commit/3e59ba847964d7648ac8df58aed1f64f0150dd7b...
-
Done (on the sourceforge.net repository, which is the only one I'm involved with, and with a slightly different error message). Denis
-
Abort autogen.sh when pkg-config is absent (cf bug #5).
-
Hi James, All right... but still, I think your distribution's packaging is somewhat broken. For example, in Fedora, the gtk2-devel package containing the header files for compiling GTK2 applications requires as dependencies all the other packages needed to compile GTK2 applications, including pkgconfig. Same in Ubuntu. My impression is that most major distributions do this, making it much easier to develop software on a system that was initially set up purely as a desktop, so the problem you encountered...
-
Hi Denis, Thanks for getting back to me. I have a few responses, with the last one first. Most people won't develop Xournal, so they will never run into this problem. Of the people who run some linux distribution and do, everyone will run into it, whose distribution does not come with pkgconfig or the correct replacement; ie everyone who's running a distribution which was initially intended for desktop users, and they are now able, at least in principle, to expand it into a software development platform....
-
This does make some sense, but given that autogen.sh already aborts anyway because things can't complete further, the only benefit is a slightly clearer error message. I am not sure how helpful that will be, though, or how often people run into this problem these days. Denis
-
I have pull-requested a fix that makes sense to me, which is one line in configuration.ac, to abort the autogen.sh if the offending macro is undefined. Does it make sense to you-all? https://github.com/xournal/xournal/pull/5
-
I'm increasingly thinking that the simplest solution would be to change the text tool cursor to something else (a pointer with a little 'T' next to it?) that doesn't look like a text I-beam, so as to not suggest an alignment that doesn't exist... (Ideally we'd have better-looking and more appropriately sized cursors altogether, but the GTK2 function we use for handling cursors is rather limited, and I don't have the energy to devote to this...) Denis
-
On my platform (Trisquel 11, Xournal 0.4.8.2016), the active spot on the text cursor is (correctly) in the vertical middle, and the top left corner of the text box is immediately to the right of the I-beam. On my platform, the largest cursor is 256x256, so in principle, there could be a variety of text cursors, depending on the text size and magnification, including something to indicate text larger than the largest cursor. I think that, to make this sensible, they would have to be procedurally generated....
-
Another implicit function declaration/header inclusion fix
-
Extremely strange. I had actually already added those into src/xo-image.c on December 14 2021 in my working directory, but forgot to commit the changes to the git repo. Fixed, and sorry.
-
Add missing include directives in xo-image.c
-
Florian Weimer created ticket #93
Another implicit function declaration/header inclusion fix
-
Thanks for the suggestion! I'll keep it in mind - but not sure how easy it is to implement, xournal's cursor handling is a bit rudimentary... Denis
-
Ross Morrish created ticket #228
Option to have your pen highlighted.
-
Lars Kellogg-Stedman posted a comment on ticket #127
Xournal is also not set up to figure out what software you'd want to use to open links; I'd need to figure out how evince goes about it. For the record, Xournal doesn't need to know how to open links; it just needs to have a configuration option that is "command to open urls". Under MacOS this would probably be "open", under Linux this would probably be "xdg-open" (to use your default browser) or something like "firefox" or "google-chrome" (to use a specific browser).
-
Due to xournal's Linux origins and the much better support for Wacom and Wacom-compatible tablets on Linux, and on the compatibility layers used by the Windows port, I expect that independently of the intrinsic qualities of your tablet, a Wacom or driver-compatible model is likely to work better in Xournal. But no promises.
-
Tripti Chauhan modified a comment on ticket #81
Have you ever try huion tabletes check out here- https://www.microworldinfosol.com/shop/product-category/huion/
-
Have you ever try huion tabletes check out here-https://www.microworldinfosol.com/shop/product-category/huion/
-
I don't understand why this is happening, as the image should always appear at the location of the button release event. If the image appears at the wrong location it means xournal got the wrong location for the button event. Does it matter which device you use to click to insert the image? (mouse, touchpad, stylus, etc.) ? Does disabling Options -> Use XInput help with this behavior? (if you have a stylus/touchscreen you probably don't want to leave it disabled, this is only for debugging purposes)....
-
Tiber created ticket #223
Image pasting fails/misplaces image
-
Mauricebis, I am confused since your previous message from last January seem to be referring to versions of xournal++ (1.0.19, 1.0.20 are not versions of xournal). Which one is your request about, xournal or xournal++? Those are two different pieces of software, and I have nothing to do with the latter. Regarding xournal, I am not particularly keen to repackage anything at the moment due to lack of time and lack of clear consensus about what is best. I and many others with styluses prefer the smaller...
-
mauricebis posted a comment on ticket #18
Any possibility of getting that version with bigger cursor as a package ? That'd be great.
-
Yes, the compatibility layer between GTK2 and Wayland has improved enough that it does seem to be working just fine nowadays. (Also on my system - Gnome on Wayland on Fedora 33). Denis
-
Douglas Silva modified a comment on ticket #180
I believe this is no longer valid. I'm on Debian 11 GNOME on Wayland and Xournal seems to be fully functional on it.
-
Is Xournal working on wayland now? I'm on Debian 11 GNOME on Wayland and it seems fully functional. There is only one visual glitch, and I'll open a ticket about it shortly.
-
The text file "INSTALL" gives some notes for how to do this (assuming you are on linux -- for windows it's a lot more complicated, see BUILD-NOTES.win32). Basically, you need to have the development packages for gtk2, libgnomecanvas, poppler and a few others (if you are using Fedora the packages you need include: autoconf, automake, gtk2-devel, libgnomecanvas-devel, poppler-glib-devel, and the dependencies of those). Then run "./autogen.sh" in the main directory; if it complains about missing packages,...
-
Adrian Obuhov posted a comment on ticket #18
Hi, I've changed the code line as suggested, but where can I find information about how to compile the files?
-
Fix smoothing of speed data for strokes with speed-dependent width
-
speed-sensitive pen width option ("fountain pen" effect)
-
Daniele La Prova posted a comment on ticket #222
My friend, i'd kiss you if you were by me, exporting GTK2_RC_FILES works just fine! Seems like my distro does not manage gtk2 themes anymore. Before, there were two distinct settings, one for gtk2 theme and one for gtk3 theme. Now there is only one generic gtk setting. I guess it refers to gtk3 apps only. I can't even find the config files mentioned in the Arch wiki. Thank you for your support!
-
There is something very wrong with your GTK2 icon theme (or rather, it's not compatible with the lighter colored toolbars that Xournal uses), but I'd argue this is not a Xournal bug, it's a bug with your theme settings. The icons that show up normally (those on the second row) are hardcoded in Xournal, the top row icons are system icons and theme-dependent. Important: xournal uses GTK2, not GTK3 like most current GTK software with a few notable exceptions, so the theme settings are different -- you...
-
There is something very wrong with your GTK2 icon theme (or rather, it's not compatible with the lighter colored toolbars that Xournal uses), but I'd argue this is not a Xournal bug, it's a bug with your theme settings. The icons that show up normally (those on the second row) are hardcoded in Xournal, the top row icons are system icons and theme-dependent. Important: xournal uses GTK2, not GTK3 like most current GTK software with a few notable exceptions, so the theme settings are different -- you...
-
System icons are almost invisible
-
Oh ok, thanks -- glad to hear that it happened only on one occasion and isn't systematically crashing every time. (That makes it harder to know exactly what went wrong, but it does mean that, if you enable auto-saves to protect yourself against crashes, xournal should still be mostly usable :-) Denis
-
Oliver G. posted a comment on ticket #221
As of now, it has only happened one time and I can't recall though when it happened exactly, but I'll watch out when it happens again. Thanks for the quick response, thought it would be only fair to help and share my experience.
-
Does this specifically affect images copy-pasted from 'Snip & sketch' or do you encounter this issue with images copy-pasted from other applications? (eg from the photo viewer or paint or ...?) Does this only happen if you copy-paste then immediately try to rescale, or also if the image has been copy-pasted earlier, you've been writing more with the pen, perhaps you even saved and closed xournal then reopened the file, and later on you select and rescale the image? In other terms, what would be useful...
-
Xournal not responding after manipulating size of pasted image
-
Luciano Antonio Siqueira created merge request #8
Added Undo option to the button mapping menu
-
ti-nok created merge request #7
Add option to keep the brush size constant when zooming
-
Add an option for inverting the scroll direction of the spinPage-Widget
-
Just added an option to the config file for setting the zoom factor for Ctrl+scroll zoom
-
Give back focus to canvas after scroll-wheeling on spinPage
-
shorten_Menus bugfix for toolbars
-
Emmanuel Favre-Nicolin posted a comment on ticket #69
This feature would be most interesting. I think I could achieve the insertion of pdf additional pages,in the case in which additional pages were added in the end of the pdf. When adding pages, in the actual version of xournal++, when using the option to add pdf with a pdf background, there is an option to select unused pdf pages. I added 2 new pages in a pdf and could include them inside the xournal file. Of course this not automatic but in my case it solved my "problem.
-
I've added to the GIT repository a quick hack for this -- essentially equivalent to what was proposed by "sadf" above, except with a less steep zoom factor (1.1 instead of the zoom factor used by the toolbar and shortcuts). It still has the same limitations -- it only works with XInput enabled (hence likely not in the Windows version), it zooms around the center of the view rather than the position of the cursor, and there's a lot of visual tearing if you zoom in too far. Sorry -- it's a useful feature...
-
control+mousewheel scrolls in/out (only if XInput option enabled) (2nd attempt)
-
control+mousewheel scrolls in/out (only if XInput option enabled)
-
Fix implicit function declarations by including config.h in ttsubset/*.c
-
phbr posted a comment on ticket #184
Thanks for your work, I use your software almost every day. I'm digging up this old request, but this feature would be really interesting to improve the user experience. I use v. 0.4.8.2016 on Kubuntu 20.04.
-
Agree. Using the new input system in preferences, the cursor is too tiny. Now, to get the arrow instead, if I'm not mistaken, there wouldn't be the need to recompile since by ticking the option off, the cursor reverts to the standard arrow. Personally, I prefer the new input system because the screen is more stable and better for eyesight but with a bigger point. Also, I personally prefer the darkness of the writing in version 1.0.19 compared to light gray in version 1.0.20. It would be good to have...
-
paolo muratore-ginanneschi posted a comment on ticket #220
Hi again, I installed XQuartz. No improvement in xounal but xournalpp on its turn stopped working (no input possible). I then removed XQuartz, xournalpp back to normal, xournal still lagging. I tried to install xournal via macports but x11 conflicts prevented it start. I did not have time to inquire that any further. I suppose your intuition is correct. Concerning CFLAGS the macport ticket which helped me is https://trac.macports.org/ticket/61147 Thanks again
-
Thanks for the details -- very helpful even though I must admit that I'm completely at a loss about what to do, or which library to consider most suspect in this. One question might be whether other GTK2 applications have the same problem (the main one these days is GIMP if you get the stable versions 2.10.x) are similarly affected. (Xournalpp uses GTK3 which can talk to macOS via different means). One possibility is that it's not even a library but rather an X server / X11 compatibility layer issue....
-
Hi Denis, thanks for your swift reply, I really apprecite it :) ! I believe the problem emerged after a library upgrade. I use homebrew to install open source (it works like apt-get in debian/ubuntu linux). In the past I never had the need to pass CFLAGS to the compiler to install, standard instructions worked. I say I believe because recently I had to reinstall macosx from scratch. Before reinstallation xournal worked without issues. The lag is about half a second. Not noticeable if I draw a line...
-
Sorry I am not familiar with how xournal ports behave on macOS (I don't have a mac). If you previously had an older version working fine on a mac with the same tablet -- is this a new problem with the latest version of macOS / libraries / ... ? How much lag is there? (roughly -- half a second? 2-3 seconds? stroke only shows up after you lift the pen?) Does it matter if you draw short strokes (say a dotted line) or long ones? (a long curve that loops a lot) ? Does drawing fast vs drawing slow change...
-
Wacom pen input lags
-
Engehausen posted a comment on ticket #219
I don't know why, but now it seems to run just fine. I think this ticket can be closed. Thanks again! - Peter
-
On 1/13/21 11:21 AM, Engehausen wrote: Update: Oh dear, it still crashes afer a while. But I'll try some more settings. I'm very sorry to hear this. I'd suggest trying to see if there is an update to the tablet drivers, or something of the sort -- but failing all else, you could also look at Xournalpp which is a spin-off that got rewritten from scratch on different technical foundations. https://github.com/xournalpp Not sure if it works on your system but it's worth a try... (alas the stated list...
-
Dear Denis, I disabled "Use XInput" and now it works! Many thanks for that! Now I will hopefully enjoy your good looking program. Thank you very much for your quick reply! With kind regards Peter
-
outdated ;-)
-
Dear Denis, I disabled "Use XInput" and now it works! Many thanks for that! Now I will hopefully enjoy your good looking program. Thank you very much for your quick reply! With kind regards Peter Am 13.01.2021 um 15:22 schrieb Denis Auroux: Sorry to hear this. The Windows version is not as well supported as the linux version, due to my lack of familiarity with Windows, and I'm also not familiar at all with Gaomon tablets so don't know how they work internally... hence it might not be possible for...
-
Update: Oh dear, it still crashes afer a while. But I'll try some more settings. Am 13.01.2021 um 15:22 schrieb Denis Auroux: Sorry to hear this. The Windows version is not as well supported as the linux version, due to my lack of familiarity with Windows, and I'm also not familiar at all with Gaomon tablets so don't know how they work internally... hence it might not be possible for me to resolve this. Nonetheless: in the Options menu, is the first entry "Use XInput" grayed (disabled)? or if it...
-
Sorry to hear this. The Windows version is not as well supported as the linux version, due to my lack of familiarity with Windows, and I'm also not familiar at all with Gaomon tablets so don't know how they work internally... hence it might not be possible for me to resolve this. Nonetheless: in the Options menu, is the first entry "Use XInput" grayed (disabled)? or if it is enabled, do the crashes happen both when it is selected and when it is deselected? When it is disabled or deselected, Xournal...
-
Xournal crashes all the time with a Gaomon Tablet M106k Pro
-
Ticket moved from /p/xournal/bugs/218/
-
I just pronounce it 'ksournal' but I'm very open minded about how people choose to pronounce it. And if your language has a 'kh' sound (greek chi, russian X, ...) it's definitely fine to use it to pronounce 'Xournal' if you wish to. Denis
-
Colin Macdonald created ticket #218
pronouciation of Xournal
-
fix author's email address :|
-
CLAUDIO BRUZZESE posted a comment on ticket #217
Thanks for Your interest Denis! Answer to Your question: actually, no. I have noticed that the "UseXInput" option under "Options" (which enables features such as "pressure sensitivity") becomes ineffective, which produces the effects I described before. I use a Huion Kamvas 22 plus under Win 10 since cannot find drivers for Deb Buster...
-
Sorry to hear about this issue. Yes, it does seem like a bug; unfortunately I'm not really able to do any serious testing, as I don't even have a working Windows laptop at the moment + don't understand how Zoom's sharing works. (In linux it also has some unpleasant side effects, but mostly some small display bugs -- nothing as drastic as what you report with the Windows version). Just in case, I would suggest checking whether you have the latest version of the Wacom pen driver, and the latest version...
-
Xournal disabled pen input under Zoom's desktop sharing in Windows 10
-
Jim Cline posted a comment on ticket #216
Hi Denis, I think you nailed it; I will investigate further. Thanks very much for your suggestion. regards, Jim On Mon, 30 Nov 2020, Denis Auroux wrote: I also can't imagine what it's doing during all that time, apart from a network timeout of some sort in the initialization of some library that xournal relies on. It does sound like something is messed up with your system. Do any other GTK2 or Gnome applications slow down at start (for example... gimp? eog?) I know this was about an older release...
-
Yes, if I do "dbus-launch xournal" or run xournal as root, there is no delay, so definitely a dbus issue. thanks again! On Mon, 30 Nov 2020, Denis Auroux wrote: I also can't imagine what it's doing during all that time, apart from a network timeout of some sort in the initialization of some library that xournal relies on. It does sound like something is messed up with your system. Do any other GTK2 or Gnome applications slow down at start (for example... gimp? eog?) I know this was about an older...
-
I also can't imagine what it's doing during all that time, apart from a network timeout of some sort in the initialization of some library that xournal relies on. It does sound like something is messed up with your system. Do any other GTK2 or Gnome applications slow down at start (for example... gimp? eog?) I know this was about an older release of Ubuntu, but just in case, see https://askubuntu.com/questions/1184774/some-applications-on-ubuntu-19-10-very-slow-to-start pointing back to an even older...
-
xournal extremely slow to initialize
-
Ralf posted a comment on ticket #215
I found a work-around. :D The issue stems from fully transparent pixels being normalized to black, and that black leaking through because of imprecise alignment of RGB data and the softmask. So the fix is to not have any fully transparent pixels. The following snippet replaces all fully transparent pixels by white almost fully transparent pixels: convert signature.png -channel all -fx 'a==0 ? rgba(255,255,255,0.00001) : u' signature_for_xournal.png The resulting PNG file can be embedded into PDF...
-
pdfimages extracts an image where the transparent pixels are black. So looks like something in the Xournal export pipeline is normalizing transparent pixels to black? I reported a poppler bug at https://gitlab.freedesktop.org/poppler/poppler/-/issues/975.
-
Another small comment: pdfimages (in the poppler-utils package on most distributions) is a good tool to export back the RGB image and the s-mask (as a grayscale image) out of the PDF, just to check what got embedded into the pdf during export (in particular, what color the transparent pixels have in the RGB image that actually gets embedded into the PDF and overlaid with the grayscale transparency mask when the PDF file is rendered). (Use: "pdfimages -png file.pdf images" to produce a bunch of files...
-
Ah btw I should link this great resource for how to manipulate alpha channel colors: https://www.imagemagick.org/discourse-server/viewtopic.php?t=13746
-
Even when I make the alpha channel pink, I see no pink in these artifacts. Looks like something further along the pipeline resets the color of transparent pixels to black, or so.
-
Oh! I had assumed the black edge was a bit of a black pixel that failed to become completely transparent, but it must be something else going on then... strange! Really sorry to not be more helpful. Denis
-
According to "convert signature.png -alpha off show:", my transparent pixels are now white (and indeed have been white before), but that does not seem to help unfortunately...
-
Regarding Gimp, for my experiments to day I had a white brackground and then used the "pencil" tool set to "erase" and the resulting transparency was still causing problems. Also the issue https://gitlab.gnome.org/GNOME/gimp/-/issues/4487 that you linked seems to suggest they want to change the default... but so far they did not, it seems (judging from the behavior of my installation).
-
Regarding Gimp, for my experiments to day I had a white brackground and then used the "pencil" tool set to "erase" and the resulting transparency was still causing problems. Also it looks like Gimp might actively delete the color value of transparent pixels to avoid information leaks: https://gitlab.gnome.org/GNOME/gimp/-/issues/4487
-
Thanks for the detailed respone! In practice, the only two ways I can see to avoid the artifact are to use a solid white background, or make sure that the pixel values of the transparent part of the image are set to RGB=white rather than black. I did not know those pixels still had color values that could matter. Is there any way to control that value e.g. when using Gimp to prepare the PNG file? I would also consider drawing the attention of the poppler developers to this issue by filing a bug there,...
-
Yeah, not having a touchpad is the reason why I need to resort to a pre-scanned image.^^
-
I'm pretty much a novice with Gimp, but transparent pixels definitely have an RGB value -- especially because you could make them only partially transparent and then the color matters (each of the RGBA channels is an 8-bit value in a transparent png). I don't know how you would specifically modify the RGB values of fully transparent pixels in Gimp; I found a thread suggesting that gimp does not destroy any RGB values when adjusting the alpha values of a previously non-transparent image; and in particular...
-
Thanks for the detailed respone! In practice, the only two ways I can see to avoid the artifact are to use a solid white background, or make sure that the pixel values of the transparent part of the image are set to RGB=white rather than black. I did not know those picels still had color values that could matter. Is there any way to control that value e.g. when using Gimp to prepare the PNG file? I would also consider drawing the attention of the poppler developers to this issue by filing a bug there,...
-
I'm afraid xournal with the default settings does NOT do anything with the image except ask the Cairo library (which is the standard one used by linux applications for this purpose) to draw the image into the PDF. The "legacy PDF export" basically reproduces by hand what Cairo does: add the image into the PDF file in what is considered the standard manner. The issue is how alpha channel is handled in the PDF specification for images: they get separated into an RGB image + a "soft mask" that is PDF's...
-
Some furhter experiments seem to indicate that when there is transparency in the image, xournal draws a border around that, but it does not draw a border around the outside edges of the image. It would be great if there was a way to disable this border.
1 >