[scribus-dev] Scribus CTL
Fahad Al-Saidi
fahad.alsaidi at gmail.com
Wed Jan 20 17:00:56 UTC 2016
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 listscribus-dev at lists.scribus.nethttp://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/719ab555/attachment.html>
More information about the scribus-dev
mailing list