[scribus-dev] Scribus CTL

Craig Bradney cbradney at scribus.info
Wed Jan 20 18:27:27 UTC 2016


We should be able to set some basic timers on the layout code for a frame of Latin text, and then run the same tests with Latin text with the CTL code in place. Then run similar tests for CTL texts. IIRC Andreas had some QTimers in the layout code already.

For the initial import we would want to see little to no change for Latin texts at a minimum.

> On 20 Jan 2016, at 18:00, Fahad Al-Saidi <fahad.alsaidi at gmail.com> wrote:
> 
> Hi Craig, 
> Do you have any idea how to make that benchmarks? Or do they available somewhere?
> 
> Right now I am thinking how we can test boxs implementation to the current implementation.  how we can know that regressions happend?
> 
> Regards, 
> Fahad
> 
>> On 20 Jan 2016 14:03, "Craig Bradney" <cbradney at scribus.info> wrote:
>> It is not that we do not have interest, it is that we do not understand the requirements to do CTL layout.
>> 
>> We're happy to review code but testing layout results is next to impossible if you do not know the rules. 
>> 
>> We will also need to see benchmarking for layout times to understand if optimisation work would be required.
>> 
>>> On 20 Jan 2016, at 10:35, Dawood al-badi <dawood.albadi at gmail.com> wrote:
>>> 
>>> Hi ale
>>> I will consider that option later when I go deeper in CTL if Andreas still not responding because it seems no one from core developers have any interest on CTL other than Andreas. If I make my changes on my own I afraid that no one will accept that huge changes so I will wait until no other option.
>>> 
>>> thanks
>>> 
>>> 2016-01-20 12:18 GMT+04:00 ale rimoldi <ale.comp_06 at xox.ch>:
>>>> hey dawood
>>>> 
>>>> i've not seen any reply by andreas, so you might want to go for an alternative -- and less straightforward -- workflow...
>>>> 
>>>> in my previous mail, i've drafted a few hints, how the integration of your work could happen.
>>>> 
>>>> depending on your own  ideas and/or other constraints you might want to build upon it and find a good way to get your work into the trunk!
>>>> 
>>>> if you need help, just raise your hand :-)
>>>> 
>>>> ciao
>>>> a.l.e
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On 12/01/16 12:09, ale rimoldi wrote:
>>>>> hi dawood!
>>>>> 
>>>>> nice to read about your progress!
>>>>> 
>>>>> i think that for the global architecture andreas will have to give you the ok...
>>>>> 
>>>>> on the other side, the longer you wait with sending your patches, the harder it is to
>>>>> 
>>>>> - integrate them into the scribus trunk
>>>>> - make sure that they don't break anything
>>>>> 
>>>>> i'm not skilled with CTL and i only know a bit of scribus code, but i skimmed through the diff between your branch and andreas' one and what i saw looks good...
>>>>> 
>>>>> since andreas did not fork the scribusproject repository, i cannot use github to check for the differences between his branch and the trunk... so i cannot tell how different your code from the current trunk...
>>>>> 
>>>>> my suggestion is:
>>>>> 
>>>>> - become confident that your changes do not break non-CTL rendering on screen and in the PDFs (you can ask the community to compile your version and try it with their documents)
>>>>> 
>>>>> - create a new (github) repository that is based on scribus trunk (as an example by forking scribusproject's github repository).
>>>>> 
>>>>> - as far as possible, add branches that contain atomic changes to the scribus code. describe each time why you are making the changes and what is the final goal. and create patches that change one thing at a time
>>>>> 
>>>>> - you can also create one branch with your current code (but based on trunk instead of avox's repository), so that it's easy to get a full view of the differences between your current state and the trunk. that way you/we also can check if your code can still be applied to the current trunk!
>>>>> 
>>>>> - start by sending patches that only contain new formatting for the code (thinks like indents...)
>>>>> 
>>>>> - continue with patches that do not change the logic of the code (like adding new structures; of course you will have to explain why you(or avox) are adding them and link to the places where you will be using them so that the team can give you feedback).
>>>>> 
>>>>> - then, if it's possible, create patches that add one feature at a time. document what you have done and why.
>>>>> 
>>>>> - since avox is "in charge" of the whole ctl project, you might want to continue to work in your current repository based on his work, and only use the new repository for creating the patches and showing your work to the rest of the team / the rest of the community.
>>>>> 
>>>>> the alternative is to add one big patch to the bug tracker and see what happens :-)
>>>>> it might be good enough!
>>>>> 
>>>>> thanks for your precious work and have a wonderful evening
>>>>> a.l.e
>>>>> 
>>>>>> On 12/01/16 11:07, Dawood al-badi wrote:
>>>>>> Hello developers.
>>>>>> 
>>>>>> I am working in ScribusCTL with guidance of Andreas-VOX. I started to complete Andreas work and I almost finished first stage which is box implementation. This stage have a huge changes in Scribus code. I Think that when we finish and stabilize box implementation will be very difficult to merge that huge of change. Also I believe that Andreas last merge was with r20300 so we already in not updated version. Good to know that my work was to make Andreas modifications work correctly without logic and syntax error and my current state is as following. Scribus now use boxes to draw glyphs on screen correctly and it can export that text to pdf format. Although there still some bugs that I am working on it right now such as TAB and point to position. I am just wondering how can I proceed with that unupdated version because when I finish I believe that scribus will be much different from the version that I am working on now. I notice that Andreas is very buzy and he did not test my work. Now I need you to tell me if I should start to send patches of my changes or I wait for Andreas to test it and merge but in case I hope you can start test our code and report bugs
>>>>>> 
>>>>>> 
>>>>>> https://github.com/dawoodalbadi/ScribusCTL
>>>>>> 
>>>>>> 
>>>>>> regards
>>>>>> 
>>>>>> Dawood
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> scribus-dev mailing list
>>>>>> scribus-dev at lists.scribus.net
>>>>>> http://lists.scribus.net/mailman/listinfo/scribus-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> scribus-dev mailing list
>>>> scribus-dev at lists.scribus.net
>>>> http://lists.scribus.net/mailman/listinfo/scribus-dev
>>> 
>>> _______________________________________________
>>> scribus-dev mailing list
>>> scribus-dev at lists.scribus.net
>>> http://lists.scribus.net/mailman/listinfo/scribus-dev
>> 
>> _______________________________________________
>> scribus-dev mailing list
>> scribus-dev at lists.scribus.net
>> http://lists.scribus.net/mailman/listinfo/scribus-dev
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20160120/7d8421e9/attachment-0001.html>


More information about the scribus-dev mailing list