Activity for Chris Vine
-
Chris Vine posted a comment on discussion Help
Although I am the author, it is some time since I last looked at the code for efax-gtk. However, I am pretty sure that the fax top header (if that is what you are concerned with) is always in ASCII. As for efax (if you are using efax separately) from what I remember it might possibly allow an ISO-8859-7 font. You could try it and see, but as I say, I don't think this is supported by efax-gtk, nor do I remember the requirements for efax's -f option.
-
Maybe your distribution puts its library files in /usr/lib64 and /usr/local/lib64, and not /usr/lib and /usr/local/lib. If so, when configuring c++-gtk-utils and efax-gtk you need to use the --libdir option (for example, --libdir=/usr/local/lib64). Make sure also that you call up ldconfig after installing c++-gtk-utils, and that ld.so.conf has appropriate contents.
-
On HylaFAX, I don't know of any GUI interface. On saved images, a received fax is saved by efax-gtk on the file system in TIFF format. To view it, efix is used to convert that to PS for the viewer program. To print the fax, the TIFF images are sent to a TIFF GTK+ printer. The results of bringing up the print dialog and viewing from there will probably go better for you. Beyond that I don't understand the rest of your question.
-
On the resolution issue, the program uses the efix binary to convert the input fax image to PS suitable for a viewer, or to convert to TIFF suitable for printing by GTK+'s print system. The conversion to PS does seem to be incomplete in some way as you have noticed, but printing via GTK+'s print system works fine. There is little that can be done about that I am afraid, without rewriting efix. On destination number prefixes, efax-gtk is in maintenance mode (bug fixes only), so I don't plan to extend...
-
Revert last two commits: stock items now fixed in gtk+-3.24.34
-
OK, I understand. I have committed the revised translations to git. The Turkish translation seems to work OK for me. I am not sure what is wrong with the sourceforge mail system; I'll see if I can get it fixed. Many thanks.
-
Update French and Turkish translations
-
Hi, Thanks. I notice that the fr.po file contains a number of UTF-8 C2A0 characters (non-breaking space) which seem to have been put there incorrectly by your editor. I can remove them programmatically using sed but I wonder if you could look at your editor settings to check that nothing else that is unknown to you is being added. The tr.po file looks OK as far as C2A0 is concerned but since you say some lines are not displayed in the Turkish locale perhaps you could also check that there aren't...
-
Hi, To compile from git you need to run "./bootstrap.sh" to generate the necessary configure and other files. Did you do that? If you did, can you let me know what error you are getting? Can you also let me know which email address failed for you?
-
Substitute GTK_ICON_SIZE_SMALL_TOOLBAR for GTK_ICON_SIZE_BUTTON where relevant
-
Ensure adwaita-icon-theme's symbolic icons are picked up where full-color ones are not available
-
It looks like a permissions issue. Check the permissions on your /home/rcdawson/faxout directory, including its contents.
-
Correct comment
-
Many thanks. I have pushed the revision of the French translation and the new Turkish translation to git.
-
Add Turkish translation, and revise French translation
-
Thanks. I cannot extract arj files; can you forward the file with gz, lz or xz compression, or send it uncompressed? I have no idea what file attachments sourceforge accepts: if need be you can forward it to cvine @users. sourceforge. net
-
I don't particularly want to make a change to efax-gtk because as I mentioned the warning/error in this case is bogus. I know very little about Arch Linux but I suggest you turn the flag off by whatever mechanism Arch provides.
-
The -Wformat-security flag causes a compiler warning to be emitted when (amongst other functions) fprintf is passed a non-literal string with no format arguments. This is a security concern where the string may be sourced externally from user input: in particular where it can be made to contain an unexpected %n specifier. From what you say, Arch's build system is making this stronger by causing this warning to be treated as an error. In this case the warning/error is bogus. fprintf is passed a pointer...
-
The -Wformat-security flag causes a compiler warning to be emitted when (amongst other functions) fprintf is passed a non-literal string with no format arguments. This is a security concern where the string may be sourced externally from user input: in particular where it can be made to contain an unexpected \n character. From what you say, Arch's build system is making this stronger by causing this warning to be treated as an error. In this case the warning/error is bogus. fprintf is passed a pointer...
-
Ah I didn't notice your dial command failure. That has nothing to do with the T, which tells efax to use tone dialling. Most likely the failure is caused by you having spaces in the file name. If not, possibly your modem is not linux compatible. Also, try setting the Modem Class to Class 1 instead of auto.
-
The whole purposes of lockfiles in /var/lock is to enable a single hardware resource (in this case, a fax modem) to be shared safely amongst different users. Accordingly, that directory should ideally be world readable/writeable. From what you say Arch linux is defective by not doing that. The best thing to do in that case is to see what group /var/lock belongs to with ls -l /var (or if it is a symlink to /run/lock, with ls -l /run), and add yourself to the group concerned - see the Arch linux documentation...
-
Providing a lock file is I think desirable where different users may wish to access a single hardware resource, and /var/lock is the traditional directory for that. As the standard directory for this, it is the preferred choice because it will not only prevent more than one efax-gtk user accessing the modem device concurrently, it will also prevent a user of a different program doing so concurrently with a efax-gtk user provided that other program also respects lockfiles. /var/lock should preferably...
-
Providing a lock file is I think desirable where different users may wish to access a single hardware resource, and /var/lock is the traditional directory for that. As the standard directory for this, it is the preferred choice because it will not only prevent more than one efax-gtk user accessing the modem device concurrently, it will also prevent a user of a different program doing so concurrently with a efax-gtk user provided that other program also respects lockfiles. /var/lock should preferably...
-
Providing a lock file is I think desirable where different users may wish to access a single hardware resource, and /var/lock is the traditional directory for that. As the standard directory for this, it is the preferred choice because it will not only prevent more than one efax-gtk user accessing the modem device concurrently, it will also prevent a user of a different program doing so concurrently with a efax-gtk usesr provided that other program also respects lockfiles. /var/lock should preferably...
-
On a postscript viewer, you can use evince (which is what I use - ' evince --preview'), and KDE has something equivalent. Any PS-capable viewer will do.
-
I can't help with the icons I am afraid. The ones supplied are based on what was needed to get GTK working some 10 or so years ago when efax-gtk was first written.
-
On the appdata file, note that efax-gtk is GPL-2.0 or higher, not LGPL (the c++-gtk-utils library used by efax is LGPL-2.1 or higher, and of course GTK is LGPL-2 or higher).
-
Hi, That sounds like a great idea. I don't know how flatpak works so I am content for you to have ownership of the app repository on flatpak. All I would ask is that the latest version of efax-gtk is used (which is what you propose). I see there is a build failure on the part of the flatpak bot, which appears to be because efax-gtk requires a dbus session message bus to be running for the user and it appears that that is not the case. See the README under the heading "DBUS". Since many other programs...
-
Update copyright notices
-
Include sys/sysmacros.h where necessary to find 'major' and 'minor' macros
-
Update README about /etc/fstab entries
-
Update README about /etc/fstab entries
-
Update README about /etc/fstab entries
-
The unexpected response warning is unlikely to be a problem. You have probably just received some calls on the landline while the modem was connected and that condition will be cleared when the modem is initialized. So far so the "can't open page" warning is concerned, assuming the file /home/rcdawson/faxout/Schiff29.ps exists, there are two possibilities: (i) you don't have ghostscript installed, or (ii) the permissions for directory /home/rcdawson/faxout or for file /home/rcdawson/faxout/Schiff29.ps...
-
The unexpected response warning is unlikely to be a problem. You have probably just received some calls on the landline while the modem was connected and that condition will cleared when the modem is initialized. So far so the "can't open page" warning is concerned, assuming the file /home/rcdawson/faxout/Schiff29.ps exists, there are two possibilities: (i) you don't have ghostscript installed, or (ii) the permissions for directory /home/rcdawson/faxout or for file /home/rcdawson/faxout/Schiff29.ps...
-
Bump micro version number
-
Bring to release level 2.2.20
-
Enable FilePrintManager dialogs to be resizable
-
Enable FilePrintManager dialogs to be resizable
-
Enable FilePrintManager dialogs to be resizable
-
Deal with test breakage with GTK >= 3.99.3
-
Update documentation
-
Update documentation
-
Update documentation
-
Update documentation
-
Update documentation
-
Update documentation
-
Yes this is a problem with some (most) postscript viewers. As a work-around, you can get a better image by pressing the print button and then choosing "Preview". You also get a better image by choosing a "200%" viewing ratio (but then of course the page is very large).
-
Bump version number
-
Bring to release level 3.2.15
-
Fix build for gcc-10
-
Add fixes for gtk-3.98.4, and for GTK4 compiles require >= 3.98.4
-
Fix margin property changes in gtk-3.98
-
It is the page size (or pixel size) which I think is the immediate problem.
-
You could try adding -dUseBigTIFF to the ghostscript parameters in the get_gs_parms() function in efax_controller.cpp and recompiling, but I doubt it would work because I don't think efax can handle BigTIFF. Assuming it doesn't work, then either rescale your document page size to something more reasonable or send your document by email instead of fax. No, I don't know what utilities might carry out such a resizing for you: you could try bringing up the PDF document in a document viewer and try printing...
-
Update documentation
-
Add fixes for gtk-3.98.1
-
Update documentation
-
Update documentation
-
Yes it looks as if you are right. You could probably get it to work with an old style serial modem with a USB -> RS232 converter but that hardly seems worthwhile.
-
You might want to try compiling efax-gtk-3.2.14 for native MacOS. It works with the BSDs so it stands a chance of working natively, although I know little about MacOS other than that it is a BSD derivative.
-
Possibly you have not run ldconfig. Possibly /usr/local/lib is not specified in /etc/ld.so.conf. Possibly it is looking in /usr/local/lib64, or possibly the /usr/local prefix is not catered for at all. To change to /usr/local/lib64, look at the --libdir configuration option.
-
Correct tray action hiding action
-
Bring to release level 1.4.5.1
-
Correct tray action hiding action
-
Bring to release level 1.2.7.1
-
Correct tray action hiding action
-
Bring to release level 1.0.18.1
-
Nothing has changed with respect to the system tray. If you run it on an X11 desktop which supports them, they will appear. You cannot have a system tray with gnome under wayland.
-
3.2.14 is on sourceforge now.
-
I'm glad it is solved. If you want to use it under wayland I suggest you download version 3.2.14. It saves you having to set environmental variables as with 3.2.13.
-
It's a long time ago that at looked at this. It would probably require going through the efax source code. Can you google for the flow control string for your make of modem?
-
Ah, just read your latest message. If it works for efax it will work for efax-gtk. It's almost certainly the params you are using to intialize the modem.
-
That's disappointing. I can't really say what the problem is. I have two test modems I use, one a standard Hayes modem, and one a Conexant USB modem, and both work OK for me. In case your ghostscript does not handle PDF files correctly, try sending a short page over the CUPS interface. Something like /usr/sbin/lpadmin -p FaxPrinter -E -v socket://localhost:9900 will set the fax printer up for you, and you can try sending that.
-
Bring to release level 1.4.5
-
Bring to release level 1.2.7
-
Bring to release level 1.0.18
-
Update copyright notices
-
Update copyright notices
-
Update copyright notices
-
Update copyright notices
-
Bring to release level 3.2.14
-
This may be a wayland issue which is fixed in version 3.2.14. Try running it with GDK_BACKEND=x11 efax-gtk If that fails then there is something else amiss: probably you have some incompatible binary deb packages installed with your playing about with this.
-
You only need one of the c++-gtk-utils versions installed. I suggest c++-gtk-utils-2.2.19. Your next error arises because you do not have libtiff/libtiff-devel installed. You may find you are also missing other devel packages, because devel packages are not installed on ubuntu by default. That is why I suggest you look for a PPA. If you do build from the tarballs, they will go in the /usr/local prefix by default. Make sure you run ldconfig after installing a library there and that /usr/local/lib[64]...
-
If you search google you will see there are PPAs for c++-gtk-utils for ubuntu. I have no idea how good they are.
-
Remove X11 specific code
-
Remove X11 specific code
-
Remove X11 specific code
-
Remove X11 specific code
-
efax-gtk 3.2.8 is quite old. If you update to a more recent version you should be OK.
-
Simplify use of std::launder with AsyncChannel
-
Simplify use of std::launder with AsyncChannel
-
Simplify AsyncChannel::pop()
-
Update copyright notices
-
Update copyright notices
-
Update copyright notices
-
Update documentation
-
Update documentation
-
Update documentation
-
Improve __cpp_lib_launder macro test
1 >