<div dir="ltr">2016-05-30 16:24 GMT-04:00 Khaled Hosny <span dir="ltr"><<a href="mailto:khaledhosny@eglug.org" target="_blank">khaledhosny@eglug.org</a>></span>:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, May 30, 2016 at 10:10:08PM +0200, Craig Bradney wrote:<br>
><br>
> > On 30 May 2016, at 22:08, Khaled Hosny <<a href="mailto:khaledhosny@eglug.org">khaledhosny@eglug.org</a>> wrote:<br>
> ><br>
> > On Mon, May 30, 2016 at 09:39:11PM +0200, Craig Bradney wrote:<br>
> >><br>
> >>> On 30 May 2016, at 21:36, Khaled Hosny <<a href="mailto:khaledhosny@eglug.org">khaledhosny@eglug.org</a>> wrote:<br>
> >>><br>
> >>> On Mon, May 30, 2016 at 09:22:43PM +0200, Craig Bradney wrote:<br>
> >>>><br>
> >>>>> On 30 May 2016, at 21:14, Khaled Hosny <<a href="mailto:khaledhosny@eglug.org">khaledhosny@eglug.org</a>> wrote:<br>
> >>>>><br>
> >>>>> On Mon, May 30, 2016 at 08:56:06PM +0200, Craig Bradney wrote:<br>
> >>>>>><br>
> >>>>>>> On 30 May 2016, at 17:26, Andreͮaͦsͯ <<a href="mailto:andreas.vox@gmail.com">andreas.vox@gmail.com</a>> wrote:<br>
> >>>>>>><br>
> >>>>>>> Hi!<br>
> >>>>>>><br>
> >>>>>>> Khaled recently committed a change to the HOST-Oman/ctl branch that changes the text coding from UTF_16 (QChar/QString) to UTF-32:<br>
> >>>>>>> <a href="https://github.com/HOST-Oman/scribus/commit/b2886e64b4aba660e4939d6cdaba066aed39d081" rel="noreferrer" target="_blank">https://github.com/HOST-Oman/scribus/commit/b2886e64b4aba660e4939d6cdaba066aed39d081</a><br>
> >>>>>>><br>
> >>>>>>> Since we have divided opinions on this issue, would you mind reviewing the discussion in the comments and add your own thoughts?<br>
> >>>>>>><br>
> >>>>>>> Best regards<br>
> >>>>>>> /Andreas<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> I don’t really see the difference because I don’t know the code. If<br>
> >>>>>> the APIs enable me, or anyone who doesn’t know the text code to do<br>
> >>>>>> stuff like insert text at a certain point for example, the it would<br>
> >>>>>> seem ok.<br>
> >>>>>> One thing that is mentioned is for example inserting a QChar.. so how<br>
> >>>>>> does one programmatically insert 1 character?<br>
> >>>>><br>
> >>>>> StoryText has no API to insert single character, inserting QChar<br>
> >>>>> apparently works because it can be cast to QString or some such. You can<br>
> >>>>> now either insert a QString and the code will convert it to UTF-32, or a<br>
> >>>>> QVector<uint> of UTF-32 code points. We might have a friendly typedef<br>
> >>>>> for this vector.<br>
> >>>>><br>
> >>>>>> I don’t have an opinion on the 16 vs 32 as long as it works so we can<br>
> >>>>>> do all operations.. read/write to file, display it, type it, export it<br>
> >>>>>> to various formats.<br>
> >>>>><br>
> >>>>> The big difference is that UTF-16 is variable length, a Unicode<br>
> >>>>> character can be represented by one or two UTF-16 code units, but<br>
> >>>>> Scribus was treating it as a fixed length encoding which is wrong.<br>
> >>>>> UTF-32, on the other hand, is fixed length encoding, so the assumption<br>
> >>>>> all over Scribus codebase can be kept.<br>
> >>>>><br>
> >>>><br>
> >>>> So… you don’t want to use UTF16 as its a variable length encoding (1<br>
> >>>> or 2 16 bit code units) and we’d need to deal with the unknown length<br>
> >>>> in all the code..<br>
> >>><br>
> >>> Right.<br>
> >>><br>
> >>>> And the downside to UTF32 is? Higher memory requirement?<br>
> >>><br>
> >>> Not sure about that, since we are not replacing 16-bit int by 32-bit<br>
> >>> int, but QChar by uint, whether uint takes less or more memory than<br>
> >>> QChar this needs to be measured (no idea how, though).<br>
> >>><br>
> >>>> Inability to<br>
> >>>> directly use QStrings in storage of text? (even though there is<br>
> >>>> QString::toUcs4 to facilitate conversion)<br>
> >>><br>
> >>> We can (and still) use QString in many places, mainly when interfacing<br>
> >>> with APIs that use QString. We just need to be careful and not assume<br>
> >>> that QString length is the same as StoryText length.<br>
> >>><br>
> >><br>
> >> What about speed? We already need to speed up the text engine massively, including rendering (or especially rendering).<br>
> ><br>
> > Converting a QString read from 25MB text file to UTF-32 takes <<br>
> > 0.4 seconds, so that does not seem to be a concern. The current slowness<br>
> > is mainly bad handling of text spanning multiple frames more than<br>
> > anything else and Andreas is working on a fix for this.<br>
> ><br>
> ><br>
><br>
> <a href="http://unicode.org/faq/utf_bom.html#UTF32" rel="noreferrer" target="_blank">http://unicode.org/faq/utf_bom.html#UTF32</a> has some fairly strong wording about slow down from using UTF32.<br>
<br>
</div></div>That seems like red herring mostly, if it were that bad we should have<br>
been using UTF-8 from the start. A 1 million character string takes ~2MB<br>
of memory as UTF-16 and a whopping ~4MB as UTF-32. I fail to see what<br>
kind of slowing this might give us in 2016. Either this page is talking<br>
about processing hundreds of gigabytes of text (not something Scribus<br>
does) or computers from the last century.<br></blockquote><div><br></div><div>Correct me if I’m wrong but that is maybe why there used to be 2 versions, one Latin and one CJK, for the commercial DTP apps. That’s now history. Back then, the computer were, as you point out, much (much) slower, hence the necessity of this kind of solution.<br><br></div><div>Louis <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
scribus-dev mailing list<br>
<a href="mailto:scribus-dev@lists.scribus.net">scribus-dev@lists.scribus.net</a><br>
<a href="http://lists.scribus.net/mailman/listinfo/scribus-dev" rel="noreferrer" target="_blank">http://lists.scribus.net/mailman/listinfo/scribus-dev</a><br>
</div></div></blockquote></div><br></div></div>