[scribus-dev] scribusCTL plan
Andreas Vox
andreas.vox at gmail.com
Sun Nov 29 18:37:51 UTC 2015
> Am 29.11.2015 um 06:59 schrieb Dawood al-badi <dawood.albadi at gmail.com>:
>
> hello Andreas
> I look to your code and I notice that you still have ScText in storytext but you mentioned in previous email that you finish working on storytext. Your plan was first to separate glyph layout from story text and that need to work on ScText which stores unicode with glyph layout. I start to eliminate usage of ScText but I saw you work on different path.I saw the new class called boxes. Can you please explain what you are trying to do. I will complete your works but I want to understand your aim first.
Hi,
ScText is only used internally in StoryText. My method is to come up with a workable interface for StoryText and then make the rest of Scribus use it. ScText can be eliminated from StoryText’s implementation later. You’ll notice that I removed GlyphLayout from ScText and all methods related to layout from StoryText.
Boxes are the future interface for layouts. It follows some ideas from TeX. I rewrote PageItem_Textframe::layout() to produce LineBoxes of GlyphBoxes instead of the old LineSpec / StoryText / GlyphLayout setup. All future implementations of PageItem::layout() will produce a text layout with a hierarchy of boxes.
The goal is to use "Box::virtual void render(ScPainter* p, const RenderOptions& renderOptions)" for all rendering: screen, PDF, PS and image export. But that needs rewriting of a lot of the PDF/PS code and merging the ScPainter and ScPainterEx interfaces.
The immediate goal is to get the code compiling again and make it work correctly for screen, PDF export and text frames. Then extend to text path and tables. Your RTL code would probably replace PageItem_TextFrame::layout() and produce a different box hierarchy. Bidi reordering should happen on box level.
/Andreas
More information about the scribus-dev
mailing list