Difference between revisions of "User:Joekidd/OpenOffice.org/Internship/PDFImport/Tasks/Moving Proper paragraphs GlyphProcessor"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Created page with 'GlyphProcessor is quite complex and makes PDFIProcessor untidy. The main reason of moving glyph processing to separate class was to avoid mess and make the code more scalable. It…')
 
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
GlyphProcessor is quite complex and makes PDFIProcessor untidy. The main reason of moving glyph processing to separate class was to avoid mess and make the code more scalable. It's required about 4 hours to move it to separate file, resolve all file dependencies and change makefile if required.
+
[[Category:Marketing]][[Category:Development]][[Category:Education]]
 +
{{DISPLAYTITLE:Required changes}}
 +
 
 +
GlyphProcessor is quite complex and makes PDFIProcessor untidy. The main reason of moving glyph processing to separate class was to avoid mess and make the code more scalable. Moreover some additional changes in function like optimizeText from drawprocessing had to be changes.
 +
 
 +
== Solution ==
 +
 
 +
GlyphProcessor and associated class have been moved to files glyphprocessor.hxx and glyphprocessor.cxx. Moreover function optimixeText was prepared to work with ParagraphLineElement instead of ParagraphElement.

Latest revision as of 19:47, 21 September 2010


GlyphProcessor is quite complex and makes PDFIProcessor untidy. The main reason of moving glyph processing to separate class was to avoid mess and make the code more scalable. Moreover some additional changes in function like optimizeText from drawprocessing had to be changes.

Solution

GlyphProcessor and associated class have been moved to files glyphprocessor.hxx and glyphprocessor.cxx. Moreover function optimixeText was prepared to work with ParagraphLineElement instead of ParagraphElement.

Personal tools