I know it's been mentioned before. I see it in the roadmap, sort of. I know there's a bug filed regarding it.
But I want to reiterate the request for Scribus to be able to handle complex scripts such as Khmer (and others for Southeast Asian languages). And I want to note a specific need that might otherwise be overlooked. Currently, Microsoft Publisher is the only page-layout program that will handle Khmer, and, well, let's just say it doesn't suffice. With so many publishing features, it's a matter of "QuarkXPress has it" or "I could really use it" and adding this new capability to Scribus makes the open-source alternative ever more viable. But in the case of Khmer and other complex scripts, it's not a question of alternatives -- the proprietary software doesn't handle it either and so there's nothing whatsoever available until Scribus can manage the job. The open-source community is the only possibility, since the commercial, proprietary vendors decline to meet the needs of these users. So I want to argue that this sort of feature ought to be given a higher priority than many others -- not because there are so many people who need it but because of the opposite: there are too few people to make it commercial. And it's a show-stopper. With something like imposition, that's a great feature, but I can still publish without it. That is, in English or German, I can. But without complex scripts, I can't publish _anything_ in Khmer. I suppose the reason it doesn't come up a lot on this list is because no one publishing in Khmer or these other languages uses Scribus. Why would they?* So there's no one to be vocal about it, except for the handful of people publishing in multiple languages, including some handled by Scribus. I don't remember now whether the first "it doesn't work in Scribus" note regarding complex scripts I found was 2002 or 2004. But this is a necessity that's been deferred for years. It shouldn't be deferred any longer. There's also an issue I haven't seen noted about this which I want to raise. In Khmer, words aren't separated by spaces -- spaces instead correspond to commas, supplying phrasing. In legacy texts, there is no space whatsoever between words. In Unicode text, usually the zero width space is used to indicate word breaks. What's critical is that the "show invisibles" capability be able to display the ZWSP. Among word processors and text editors, having tried several dozen, I've found only two programs** that can do this although virtually all the ones I tried claimed to be Unicode compatible. Without being able to see where ZWSPs are entered, checking a manuscript and fiddling with linebreaks is tortuous. It's really important that this go hand in hand with the capability to handle complex scripts. As for me, I'm an editor and a publishing person. I used my first DTP program in 1985 (and TeX before that). Publishing I know. What I'm not is a programmer, nor are any of the people I've ever encountered who are stymied by this. So it's not a question of "if you want it done, pitch in." If it were, I'd pitch in. But right now the only thing I can do is appeal to the developers to reorder the priorities. Please make this a critical feature for 1.3.6. Thanks, Roger Sperberg _________ * Yes, I'm just now beginning to participate in this project. I first checked out Scribus more than a year ago, but didn't bother pursuing it then. ** For the record they are Microsoft Word and OpenOffice.org Writer. I'm only familiar with the Windows editors. -- firstinitial lastname at gmail Cambodian Language Exercises -- cambodian.tiddlyspot.com Beginning Cambodian Reader -- cambodian-reader.tiddlyspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://nashi.altmuehlnet.de/pipermail/scribus/attachments/20070627/6a4f4411/attachment.html
