To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=64671
------- Additional comments from a...@openoffice.org Wed Jan 14 16:17:07 +0000 2009 ------- AW: So we have three modes now to distinguish: (a) Text in edit mode (b) Text drawn in edit view (c) Text in Presentation While (a) is painted by the Outliner using the OutlinerParaObject, (b) is pained from the primitive processors using the data from TextSimplePortionPrimitive2D. I think THB could clarify what (c) uses, but i think it's the MetaFile data from a Paint internally using the primitive processors, too, so it should be the same effect as looking at (b). I do not know exactly what (a) uses for painting, e.g. if the VCL Font is hold in the OutlinerParaObject's ItemSet data, but (b) uses the data provided from TextSimplePortionPrimitive2D. This includes the DXArray, Locale, FontColor and FontAttributes. These again use FamilyName, StyleName, Weight and some bolleans (e.g. Symbol). Have a look at ^drawinglayer/inc/drawinglayer/primitive2d/textprimitive2d. That data is derived during text decomposition from an outliner running in callback mode. Data is taken from the VCL Font which was handed over in that callback mode. Using that data the renderers construct a new VCL Font. This is where the Font Matching will hapen. It will get the same data that was derived from Outliner's callbacks and the handed over VCL Font. Thus, it should create exactly the same font as used in Outliner at text decomposition time. I also found out (maybe relevant) that the outliner's callback mode always gives a DXArray which is transported using the primitive and used when the renderer renders the text (using VCL again). The TextSimplePortionPrimitive2D is layouted to work without DXArray, though, but it's not used since the Outliner always delivers one. Maybe - when there is a chance to find out that DXArray is not needed - the text decomposition may create text primitives without DXArray and this could be better, but i do not know. It may have more to do with Linux font substitution; at least i have not seen this problem on Windows yet. Also, the text decomposition and the renderer paints are both at runtime on the same system (same Fonts available). HTH for the moment... --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org For additional commands, e-mail: issues-h...@graphics.openoffice.org --------------------------------------------------------------------- To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
