Hi Yanmin,
ImplWinFontEntry::InitKashidaHandling is called many times when
saving a
sample presentation as profiling OOo3.1. A guy guess that would be a
possible performance blocker. I'm also doubtful that if it really
need to
call ImplWinFontEntry::InitKashidaHandling when saving a document.
I know
Kashida is used for line justification of Arabic text. But I have no
idea
about how the function work. Would you please give me some hints or
information about ImplWinFontEntry::InitKashidaHandling?
Saving a document itself does not need to do any document formatting.
Though when thumbnails are to be generated in that process then
document gets fully formatted and rendered. This is expensive.
I've seen thumbnail generation to be the culprit of quite a few
performance problems during document export. For just creating a
thumbnail doing a full layout with every 't' being crossed and every
'i' being dotted seems like a waste of time. When you are working on
document export performance then analyzing the costs in thumbnail
creation is a worthwhile issue. I'm not sure how they are created
anyway: Is more than the first page rendered on thumbnail sized
OutputDevice?
Coming back from the big picture of thumbnail creation to the topic of
arabic justified layout,
so the call to InitKashidaHandling should only be needed if justified
arabic text is involved. Is there any in your sample documents? Is it
on the first page?
The kashida width is the width of the "kashida glyph" in the selected
font. It is needed by Writer's layout engine to layout a paragraph
which has arabic text which is to be justified. The width determines
the line breaks etc. so it also influences the page layout and the
layout of subsequent pages.
---
Herbert Duerr
du...@sun.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@gsl.openoffice.org
For additional commands, e-mail: dev-h...@gsl.openoffice.org
