Activity for Denis Auroux
-
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...
-
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...
-
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'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
-
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
-
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
-
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.
-
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)....
-
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...
-
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
-
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,...
-
Fix smoothing of speed data for strokes with speed-dependent width
-
speed-sensitive pen width option ("fountain pen" effect)
-
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...
-
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
-
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...
-
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
-
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....
-
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...
-
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...
-
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...
-
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
-
fix author's email address :|
-
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
-
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...
-
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...
-
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
-
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...
-
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...
-
So, obviously this never happened. The only way you can change shortcuts right now is by recompiling a custom version of xournal with your favorite shortcuts. This happens in src/xo-interface.c Search for "gtk_widget_add_accelerator" to find the various lines where the keyboard shortcuts are set up and modify them if needed. For example, to change the shortcut for the pen tool, find the line gtk_widget_add_accelerator (toolsPen, "activate", accel_group, GDK_P, (GdkModifierType) GDK_CONTROL_MASK |...
-
This would indeed be useful, but due to lack of time I doubt I'll be able to implement this anytime soon, at least not in the way it should ideally work. Two things I can imagine implementing sooner, in that order: 1. a way to select the whole current layer; this should be pretty easy, and if set up properly, it should already paste without any change of position when copied to a page with the same paper size. This ought to work across documents. 2. a way to duplicate the current page (with all its...
-
Yes, this has been a bug, which I believe should have been fixed by commit [ee6960] on April 16 2018: "Fix sporadic wrong detection of auto-save restores and creation of randomly named files when opening files from recently opened list" I apologize for what was a pretty bad bug. Try getting the latest source code at https://sourceforge.net/p/xournal/code/ci/master/tree/ (download snapshot in the top-right corner above the list, then follow instructions in the file called INSTALL). If you got version...
-
Alas there's no way to do this without recompiling from the source code, I think. The change is very minor though. After downloading the source at https://sourceforge.net/p/xournal/code/ci/master/tree/ (click "download snapshot" in the dark gray bar below menu) edit src/xo-paint.c to change line 61 return gdk_cursor_new(GDK_PENCIL); to return NULL; With this change, the "pencil cursor" option will instead give you the default pointer (arrow most commonly) instead. Then recompile: install any development...
-
Unfortunately, Xournal just doesn't currently have the ability to interpret the contents of a PDF file, such as for example its hyperlinks. This is not impossible to implement, by asking Poppler (which we already use to render PDF pages to serve as background for xournal) to provide a list of hyperlinks and clickable areas, but it is more work than I can manage in the foreseeable future. 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...
-
Unfortunately, Xournal just doesn't currently have the ability to interpret the contents of a PDF file, such as for example its hyperlinks. This is not impossible to implement, by asking Poppler (which we already use to render PDF pages to serve as background for xournal) to provide a list of hyperlinks and clickable areas, but it is more work than I can manage in the foreseeable future. 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...
-
I don't understand why the text ends up being on a black background. On my system, the text editing box is on a white background when the text is edited, regardless of the background color of the paper. Do you have a black theme configured in GTK (more specifically GTK2)? Regardless, when the paper background is solid (not a PDF or an image), it would make sense for the text box background to match the paper. I'll update the GIT repository on sourceforget with a quick patch to do this. Anyway: for...
-
Text edition box background color matches paper if page has a solid background (feature-request #17)
-
Ouch. The bug hasn't affected me, due to sheer luck (see below), but I had heard a colleague complain about this esp with the Windows version, and indeed the screenshots are painful. I just replicated your bug and agree it's nasty. Xournal has no way of knowing that zoom draws on its window without following proper protocol for a transparent window -- normally scrolling xournal should not be affected by a transparent window overlaid by Zoom over it. I do wonder if there is a rounding bug in the underlying...
-
Xournal already does what you want -- have you tried Control + Right Arrow? (the shortcut for "next page"). This goes to the next page, and if there's no next page, creates one. (Same for most ways of going to the next page other than scrolling: the toolbar button for "next page" and the page number +/- buttons in the status bar at the bottom also do this). Denis
-
Ctrl mouse scroll is not implemented to zoom in/out in xournal. I used to feel unsure that it should, owing to the tablet origins of xournal; it is getting common enough that perhaps the answer has become yes. I will keep it in mind as a feature request. Ctrl + and Ctrl - should work, if you use the "regular" + - keys on the keyboard. They apparently do not work if you use the + - keys on the numeric keypad of a full-size keyboard; this arguably should be fixed, but in the current state of things...
-
I am still not sure what is happening, but since the package in Ubuntu 18.04 is the old 0.4.8 (I think?), presumably missing a large number of bugfixes included in the more recent version 0.4.8.2016 (or in the git repository), it would be good to test if this still happens if you compile/install the current version of xournal... Denis
-
Fix bug where auto-saves would repeat instantly while user is drawing. Make default auto-save frequency less aggressive.
-
Good luck! Another thought -- I don't think any of the bugfixes to xournal since the version packaged in Ubuntu 18.04 would solve this issue, since my guess is that the problem lies elsewhere, but just in case, if your package version is 0.4.8 (or 0.4.8-1), please try the more recent version 0.4.8.2016 which contains a number of bugfixes. Ubuntu 19.04 has a package for it, or you can try to compile it from the source code -- you can download the latest stable code at https://sourceforge.net/p/xournal/code/ci/master/tarball...
-
Can you open files? Do you have similar problems with other GTK2 applications. The open/save dialog boxes are "standard ones" generated by system libraries (Gnome and GTK working together), not by xournal, and slowdowns are likely caused by some inner workings of Gnome looking to either explore network locations or something like that. Possibly related bug with slowdowns of open/save dialog boxes: https://forum.manjaro.org/t/gtk-file-picker-chooser-extremely-slow/41879 (there are others) Does the...
-
I think there is something unusual with the input device setup on your system -- on other Surface Pro 3 installations, "xinput list" has been reported to give at least two pointer devices called "NTRG0001:01 1B96:1B05" for the touchscreen, and "NTRG0001:01 1B96:1B05 Pen" for the pen. Here there seem to be identically named devices under pointer and under keyboard, but not a separate pen device. I am not sure if this is the root cause of the problem you are observing, but it might well have something...
-
I'm sorry I am not familiar with the surface pro 3 or with Pop OS, but in principle it ought to work... things to check: are you running gnome on Xorg or on Wayland? Running a genuine X server (Xorg) is usually more straightforward with Xournal -- xournal recently started to become usable on Wayland in Fedora 29, running a GTK2 Xinput application over Wayland requires various compatibility layers that were pretty buggy until recently. (A quick search suggests that Pop OS uses Xorg by default so you...
-
Can you explain what happens after those first few seconds when things work ok -- does the touch then start drawing with the pen? does it not do anything at all? when you try to use the touchscreen while it's not working anymore, does the pen/pencil icon remain selected, or has the toolbar selection changed to something else? Can you please provide the output of the command "xinput list" ? 2'. (Not sure if this is applicable to Ubuntu): If at the login screen you have a choice, in the list of session...
-
Done -- it's added in the GIT repository. (No promises about an actual numbered release coming anytime soon, there's not really enough recent updates to justify it). Denis
-
Added Valencian variant of Catalan translation (Alfredo Boix)
-
Toolbar icons are very tall, reducing available space for document
-
The problem is likely that you have a file in your current working directory called white.png or something like that -- the same name as one of the icons in /usr/share/xournal/pixmaps/ Rename that file, or work in a different directory, to avoid it being loaded instead of the toolbar graphics by error. This bug has been fixed more than two years ago, and the fix is included in release 0.4.8.2016 if I'm not mistaken. Consider asking Ubuntu to upgrade their package. Best, Denis
-
Thank you for the suggestion. However, xournal is designed for taking handwritten notes using a stylus, it is not a PDF editor. It just happens to let you take handwritten notes on top of PDF files. And so the priority is to keep the user interface simple, not to become a better PDF editor. Concretely, I don't see why QPDF would have any benefits in terms of functionality over the Poppler library we are already using. It would be desirable to add to xournal features to manipulate the pages of the...
-
This bug got fixed in October 2015. Commit [f5c777], 2015-10-09, Bug #160: avoid data corruption when export-to-PDF overwrites the PDF being annotated (but warn the user nonetheless). https://sourceforge.net/p/xournal/code/ci/f5c777d4e081a886baed8bbe2aee4d84b3562722/tree/ If your distribution isn't up to date, please ask the maintainer to update. Meanwhile, you can grab release 0.4.8.2016 which includes this and several other bugfixes. -- Denis
-
Wait, you reported in support-request #15 that this only happens when you overwrite the pdf file being edited, and there you propose as a workaround to export to a different file from the pdf file that you had opened... so which one is it? (and regardless, can you reproduce the bug with a version of xournal that is less than 3 years old ? it should have been fixed in late 2015.) -- Denis
-
Yes, this is a problem. For some older format PDFs, setting "Legacy PDF export" in the options menu might bypass this, but most form-enabled PDFs these days are in a format that our old PDF processing code can't handle; in that case, the new export involves re-distilling via gtk-print to a new PDF and right now form fields are lost; I don't know how to fix this. Denis
-
I'm aware of the problem. It's not very easy to fix, because the cursor size is not necessarily the size of the text anyway to begin with. Basically, right now, the bottom edge of your cursor will end up being the top-left corner of the text box. I agree this is annoying and just about the worst possible choice of behavior. Denis
-
No, this isn't in the official release. Denis
-
Really, the simplest practical thing is to increase the auto-save interval. Perhaps this is misguided on my part, given that not all distributions are equally stable, but the goal (which should be close to realized if you are up to date with the git repository) is that xournal just shouldn't ever crash. So, you shouldn't need frequent auto-saves, or perhaps any auto-saves whatsoever if your system is stable and you are not prone to inadvertently running out of battery. That said: your suggestion...
-
This is pretty clearly not the same issue or even remotely related, but anyway... This is a wacom driver configuration issue, based on what I found out on my system. Go to the Control Panel, under "Hardware and Sound", you should have a "Wacom Pen" entry (not "Pen and Touch", not "Tablet PC Settings") to configure the Wacom driver. It should open the Wacom Pen settings tool, in which you should have a button called "Configure Displays". Click this button and follow the instructions (which aren't...
-
I'm very sorry to hear this. This should never happen. Was your disk full? If you were saving a .xoj file to a .pdf, how come the .xoj became corrupted? (did you save it again while your disk was filling up?). If it is not cropped too badly, and the contents are not too confidential, email me your cropped xoj file (my last name at math.berkeley.edu) and I'll see if I can recover the beginning of it. Denis
-
Indeed, the Windows build has been lagging badly behind, largely because I don't always have a working windows development environment, and also because most of the bugfixes since release 0.4.8 have mostly concerned the linux version -- still, by now it's overdue. Sorry!! In the meantime, the fastest workaround for your issue should be to enable "Legacy PDF export" in the options menu, provided it works for you. Denis
-
Does this happen when "Options -> Legacy PDF export" is enabled / disabled / both ? (In either case it's not clear what we can do about it: when enabled we just copy over the existing PDF code so it shouldn't happen; when disabled we entrust the standard poppler and cairo libraries to reprocess the background PDF and they shouldn't change anything. Also: do you have a completely up to date xournal -- 0.4.8.2016 or similar derivative of 0.4.8 that includes the bugfix "export to PDF and printing: fix...
-
Unless I am mistaken, this means the Ubuntu package is hopelessly out of date -- this misbehavior was fixed in September 2014, commit [48f94d] "test ui.device_for_touch as exact match instead of substring of device name" Please file a bug report on Ubuntu asking them to update. There is a convenient bugfix release, version 0.4.8.2016, with most of the fixes added to 0.4.8 since its release, including this one -- get the source code at https://sourceforge.net/projects/xournal/files/latest/download...
-
The writing is distorted because your tablet is configured to map the pad area (which is a rectangle of given aspect) to the whole display surface (which is a rectangle of a different aspect ratio once you add in a second screen). To avoid this, you need to map the tablet area to just one of the two screens. This is the job of your system's configuration scripts, not xournal's. The magic command (which some distributions apply automatically in some use cases, but usually that is only for tablet PCs,...
-
The writing is distorted because your tablet is configured to map the pad area (which is a rectangle of given aspect) to the whole display surface (which is a rectangle of a different aspect ratio once you add in a second screen). To avoid this, you need to map the tablet area to just one of the two screens. This is the job of your system's configuration scripts, not xournal's. The magic command (which some distributions apply automatically in some use cases, but usually that is only for tablet PCs,...
-
To avoid this issue, you should simply disable Options -> Progressive Backgrounds (first you may need to uncheck the option to shorten menus since this option is normally hidden),then save preferences -- or edit .xournal/config to change the line "progressive_bg=true" to "progressive_bg=false". When this option is disabled, xournal will generate renderings of all PDF pages immediately, not just when you first look at the page. There is obviously a performance and memory consumption cost -- high-resolution...
-
Hi Sven, The problem with making the toolbars disappear is that you can't really do very much annotating (if you can't change pen colors or the like), so when I give a presentation in xournal I normally want the toolbars there -- hence fullscreen mode. The zoom can then be set using the zoom toolbar button to match page width or height as needed, and if you use View -> One Page then you won't see more than one page at a time. So... should F5 / "presentation mode" be just a shortcut for fullscreen...
-
Sorry but I do not plan to merge this anytime soon. I am glad that this patch got written and I thank you for making it available here for motivated users who really care about vi-style scrolling shortcuts, but I do not see the point of vi-style keyboard shortcuts in an application that is primarily intended for tablets. Denis
-
I am aware of this. Haven't found a great way to deal with it. GTK2 doesn't seem to have received much Hi-DPI attention, and porting xournal to GTK3 comes with issues (and lack of time on my part; though there is an experimental port by Daniel German on his github). In the meantime, I continue to suggest that Options -> Pencil Cursor is your friend (the resulting pencil cursor is HiDPI aware in Gnome 3 at least: changing the display factor to 200% in the gnome display settings will make the pencil...
-
Thank you! It's updated in the GIT repository. Denis
-
Updated Italian translation (by Marco Ciampa)
-
This would be a nice feature indeed, though it seems surprisingly harder to do than I would have expected. For tablet users this is not relevant since the cursor is where the tip of the pen is. In the meantime, Options -> Pencil Cursor will help you (except then the cursor doesn't change color when you change pen colors, but at least you'll be able to see it!). Denis
-
Ah, of course you are right I forgot to change toolsHand to colorOther. Regarding numbers: the issue is that shift+1 doesn't produce the number 1 anymore, so it gets messed up. On a US keyboard, shift+1 is exclamation mark, so one apparently needs to use GDK_exclam For Control+1 you can use GDK_1 and GDK_CONTROL_MASK, it works. For Control+shift+1, though, I had to use GDK_exclam and GDK_CONTROL_MASK | GDK_SHIFT_MASK (GDK_1 didn't work for me, just as you reported. And then annoyingly, if you use...
-
There is no default key binding (other than navigating the menu: Alt+T, C, up arrow, enter). If you want to create one, either edit the interface in glade-2, or less straightforward or less risky (glade-2 has plenty of bugs), edit src/xo-interface.c (beware glade-2 overwrites this file if you use it to generate code). To add an accelerator for the color palette which is Tools -> Color -> other, after the lines colorOther = gtk_menu_item_new_with_mnemonic (_("other...")); gtk_widget_show (colorOther);...
-
Hi, Is this any different from bug #136 ? https://sourceforge.net/p/xournal/bugs/136/ This was patched in the source code repository in 2014, and included in the bugfix release 0.4.8.2016. Please try getting an up-to-date version from sourceforge (either the repository at https://sourceforge.net/p/xournal/code/ci/master/tree/ or the 0.4.8.2016 release at http://downloads.sourceforge.net/xournal/xournal-0.4.8.2016.tar.gz Hopefully the problem will then disappear. If not then it may be a wacom driver...
-
It already doesn't do an auto-save when nothing has changed since the last auto-save -- at least it shouldn't. Window focus is probably not so relevant -- I assume most users have xournal in fullscreen and it almost never loses the focus for the whole session of work, at least when I'm inactive in xournal it's usually because I'm thinking or listening or doing something that doesn't involve switching to another application. Thanks for your thoughts in any case. Denis
-
Trying to detect lack of very recent activity is a good idea, though I'm not sure what kind of delay to use -- when taking notes or writing something one often stops for a few seconds between thoughts or sentences, and there will always be a risk that we'll be auto-saving at just the wrong time. I guess it will have to be customizable too. I won't be able to get any work done over the next few weeks though, so it won't happen imminently -- but will make a note of it for the future. Denis
-
I'm sorry that you lost work. Alas there's not much I can do for you, except recommend that you look into the autosave_delay parameter of the config file and adjust it so that auto-save works for you. In more detail: Automatic backup to a .backup is exactly the autosave feature. Every program which does auto-backups usually freezes for a short time during the backup. Xournal has a lot of data to store and its backup takes longer especially if you have a large file, and that is a genuine issue, but...
-
This is normal. Default = default for this session. If you want changes to settings to be permanent, then you need Options -> Save preferences (for a one-time change) or Options -> Auto-save preferences (if you expect settings changes to automatically be saved). Denis
-
This is a feature request, not a bug; but in any case it is questionable, because the sequence of colors shown in the toolbar is arbitrary and I do not expect you to have the same preference about what the "next color" should be. (Plus, do you really want it to go through white ?) Also, if the current color is not one of the pre-set colors (because you used the color chooser), then what should the action be?
-
Ticket moved from /p/xournal/bugs/196/
-
I can reproduce the problem with your file, though with a slightly different error (it tries to load a different font, equally unrelated to the Arial font that is needed). The problem only occurs in Windows -- the linux version opens the file without any problem. What is even more confusing is that if I separate the first few pages containing annotations from the rest, they open fine, and the remaining pages also open fine separately, it is only when all the document is in one piece that the error...
-
By the way, using the version of fontconfig packaged with xournal 0.4.8-win32, in Windows 10 Pro, I find that Marlett is indexed into the fontconfig cache but not offered in the list of fonts for entering text in xournal (probably because it is not a regular text font). I don't have any PDFs using Marlett so can't test. I created a xoj file that has some text claiming to be in Marlett font, and it loads properly (likely displays with a substitution font since Marlett doesn't include regular text...
-
A pango error message concerning a font that used to work and no longer works in xournal means that your fontconfig cache is corrupted. It is probably located in c:\Users(your username)\AppData\Local\Temp -- try erasing it, rebooting, and starting xournal again.
-
This feature has been reimplemented differently -- the resizing feature "snaps" to aspect-preserving when resizing by a corner. The selection frame turns red to indicate visually that the aspect ratio is locked. This has just been committed to the GIT repository. https://sourceforge.net/p/xournal/code/ci/07383c0374c644ca3728c9d1b954ec0fd120bc2d/ I am aware that if you were using this patch previously, it will now require a little bit more attention to aim the cursor in the correct general area to...
-
selection resize snaps to preserve aspect ratio
-
Sorry. Corrected back to your version. My understanding of autotools is quite limited, and my understanding of the packaging process is even more limited... Sorry again. Denis
-
Fix: Install html documentation in docdir/htmldir instead of html-doc
-
Once again, this patch is not going into upstream as is. I for one use button 3 as mapping for the selection tools (button 1 for drawing, button 2 for erasing), which is the most intuitive setting for tablet users with a side button on their pens. With this patch I and other users with a similar workflow have to do a counter-intuitive sequence of operations to resize freely. I plan to be working on a better version of this feature shortly. Denis
1 >
