| | [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #2148
| Application: | FLTK Library |
|---|
| Status: | 2 - Closed w/o Resolution |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | OS support |
|---|
| Summary: | Use iconv() if provided by glibc |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | timothy.lee |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | Will Not Fix |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | timothy.lee
19:51 Feb 09, 2009 |
| The attached patch against fltk-1.3 r6649 uses iconv() to convert between UTF-8 and other encodings, only if iconv() is bundled with glibc.
This shaves 200k from the FLTK library. I've tested this patch on Linux. | |
| |
| #2 | greg.ercolano
21:03 Feb 09, 2009 |
| Does this take into account compiling on Windows with Visual Studio?
I know one can get and compile iconv for windows, but it's sure nice
not to have dependencies on non-native external libs.. makes it much
easier to build/support fltk. | |
| |
| #3 | timothy.lee
00:30 Feb 10, 2009 |
| configure.in specifically checks for iconv() in libc, so iconv should not be used under VC | |
| |
| #4 | timothy.lee
23:09 Feb 23, 2009 |
| fltk-1.3-iconv-v2.patch fixes the order of the to/from encoding in iconv_open() calls. The use of iconv() calls must now be manually enabled using the --enable-iconv flag.
I've found a rather big trade-off between speed and size: iconv() is at least 2-3 times slower than the built-in lookup tables. | |
| |
| #5 | fabien
09:38 Apr 01, 2009 |
| On on hand, I'm not keen on adding a new lib dependency to fltk, this could be a problem for those who use fltk as a shared lib, because the fact that configure find it on your developer platform won't guaranty it would be available elsewhere if distributed.
On the other hand, if this iconv dep. is _not_ activated by default in configure.in (even if iconv is found), it is ok for me. | |
| |
| #6 | matt
12:55 Nov 14, 2010 |
| Not essential for the 1.3.0 release. Temporarily moved to 1.4 . | |
| |
| #7 | AlbrechtS
17:07 Jan 15, 2023 |
| @OP (timothy.lee): Please help me understand what the benefits of this patch are. Are these conversion functions actively used in current FLTK (1.4.x)?
I took as an example 'src/xutf8/utf8Wrap.c' and I see that this file is only used (compiled) on X11 and if Xft is disabled.
Current FLTK 1.4.0 and later prefers using Xft in newer versions and configurations Pango and Cairo etc. for text and drawing. If I am correct, then this patch would not bring us any benefit. Making the library smaller for outdated configs (x11 w/o xft) would not justify another dependency.
Meanwhile this STR is almost 14 years old (sigh) and the patch may not be useful anymore.
However, I may be wrong because I miss anything. Can you please shed some light on this?
PS: if we don't get an answer within 14 days this STR must be closed according to our CMP. | |
| |
| #8 | timothy.lee
03:22 Jan 25, 2023 |
| The patch is not relevant when Xft is used. The iconv() call was originally used to translate Unicode characters into the native encoding used by X11 fonts. | |
| |
| #9 | AlbrechtS
05:15 Jan 25, 2023 |
| Timothy, thank you for confirmation of my assumptions.
I hope you understand that I'm now closing this STR "w/o Resolution". After all it wouldn't reduce the library code itself because we need to keep the lookup tables anyway (it could reduce its compiled size though), and as you said in comment #4 it would be slower than using the internal tables. It would also not apply to "modern" FLTK using Xft and/or Pango.
Thanks for you patch anyway, and sorry for not working on it earlier. | |
[ Return to Bugs & Features ]
|
| |
