Cups patch works with both stable and development versions of cups. I viewed the ps file output using gs and gsx (I made a crazy way to force it to use gtk2+ and it worked hehe).
The text is bidi and shaped but there are little gaps between the letters. This is true for both the patched versions I compiled. I'll have to see if this is to be fixed or is a mistake of my own.
I stumbled across a page on the mozilla bugzilla that says that a patch for arabic text copy bug is already available. I'll look into the matter.
Inkscape turned out to be gtkmm (c++ gtk) which I don't have or use. bummer. Sodipodi is nice but has arabic problems, maybe I can coax mohammed to fix it...
Scribus has a problem with arabic, but it's probably me being hasty.
As I said gimp-print is working, but I have to figure out the proper order of compiling all this so they work optimally.
...
Comments
yep
Arabic copy and paste bug does not exist in Moziulla 1.7 and higher.
but its still in firefox :-(
inkscape is realy good I think you should bite the bullet and install gtkmm.
scribus does have arabic problems and will be the subject of an upcoming do or die.
cheers,
Alaa
"u know i once dream that the office of mobinil is from el 7`os :S and the one that answer u and tell u rasidak a girl called ghada"
I'm really honored
U know, every time alaa or Mohammed appear on my blog I feel really honored.
hmm gtkmm, I was always avoiding that, but since I always bump into good projects that use it, it may be beneficial.
I am sorry to say however that after adding all this stuff tex has no place. Or maybe if I figure out a magical way to squeeze more stuff into the livecd... (maybe squashfs?)
Confirmed I have compiled mozilla 1.8a1 and it doesn't have the bug. I am pulling 1.8a2 now from CVS and maybe I can build firefox over that and see if the bug is sitll there. Maybe I can port the arabic copy and paste patch to firefox.
I think scribus is worth a good effort, and I am happy to bring this up. I think a bug fixing do or die will also be a very beneficial experience for me.
Like wise when I reply to you
but please don't use any compressed filesystem, It'll slow the distro.
now I'm flattered ;)
I routinely strip -s binaries ( elf executables or shared so libs). No sense in debugging info in an end user distro. Man pages and info pages are also compressed... That leaves to the includes debate. /usr/include is currently 22mb. If I compress it, I think it will shrink considerably but that would hinder the driver compilation during the startup of the live-CD. The live-CD is already zisofs with overlayfs. I was thinking of replacing zisofs with squashfs. But I will never use the cloop method because it stinks. If the number of apps depending on gtkmm is high enough ( say um 3 ) it'll be worth it to include them. This was the case for the gnome libs.
du -sh /usr/share/doc 166M /
Compressing this ?
not the whole dir but as Debian is doing,
ls /usr/share/doc/x-window-system-core/
changelog.Debian.gz copyright NEWS.Debian.gz
why not include compiled drivers ? Instead of compiling them during startup ??
Debian ≠ LFS
du -sh /usr/share/doc 3.9M
I guess debian is a little talkative. About whether to compile or include a binary, I don't know if it would infringe the license, or maybe it uses some hardaware specific info that can only be procured from the target machine. Take the connexant driver as an example. It extacts info from the modem's nvram and compiles this info into the driver interface. ( OR at least I see it this way ). If I find it possible to include a binary driver package it would speed the liveCD startup considerably. ( if the system needs compilation ).