Re: Italic font bug (was: Encapsulate data access)
On Tue, Dec 09, 2003, Alexander R. Pruss wrote:
> I can't find it. Which pointer is that?
$ cvs diff -r 1.131 -r 1.132 paragraph.c
:
-if ( multiline.Italic && tContext->writeMode == DrawChar ) {
-if ( ! EndFontItalic() && tContext != NULL ) {
+if ( ! EndFontItalic() && tContext != NULL ) {
+if ( multiline.Italic && tContext->writeMode == DrawChar ) {
:
/Mike
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Italic font bug (was: Encapsulate data access)
From: "Michael Nordstrom" <[EMAIL PROTECTED]> > On Tue, Dec 09, 2003, Alexander R. Pruss wrote: > > Is that in grayfont.c or in font.c? > > Neither; it was in paragraph.c. I can't find it. Which pointer is that? Alex ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Italic font bug (was: Encapsulate data access)
On Tue, Dec 09, 2003, Alexander R. Pruss wrote: > Is that in grayfont.c or in font.c? Neither; it was in paragraph.c. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Encapsulate data access
Mike, > I have also found (and fixed) a couple of bugs in the bookmark handling > and the new italic font support. The bug in the italic font support > was that the pointer was used before the check to see if it was NULL Is that in grayfont.c or in font.c? Alex ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Encapsulate data access
On Sun, Dec 07, 2003, Alexander R. Pruss wrote: > How is rendering performance? I haven't noticed any difference and neither did I expect any at the moment; I haven't made a "final" split in paragraph.c, yet, and that's where the rendering takes place. Still, *reading* the the data is not the major factor in the rendering of the document. Anyway, the rendering will still work with pointers, it just won't have control *how* these pointers are initialised; it will get a ParagraphContext to work with, i.e. the InitializeParagraphContext function will be moved to the "data access domain". The rendering code hasn't really changed that much (it might be necessary to make some minor changes to it if we want to support DOC documents, though), so the speed should stay intact. Still, GetLineMetrics should be split into smaller functions; it's one big mess at the moment. You might want to add a comment or two to the block of code you have added to the beginning of that function ;-) /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Re: Encapsulate data access
From: "Michael Nordstrom" <[EMAIL PROTECTED]> > With the current code we are "circulating" pointers to the Plucker > data and access it directly using those pointers. This has both pros > and cons, but since I would like to get better control of the data > access I've started to "encapsulate" the data interface, so that > access to the Plucker data (record header, paragraph headers, and > paragraph data) must be done through a new interface. The only thing > the "user" of this interface will know about is the handle to the > record with the Plucker data. It is still possible to access the data > directly, but I advice against it. How is rendering performance? Alex ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
Encapsulate data access
With the current code we are "circulating" pointers to the Plucker data and access it directly using those pointers. This has both pros and cons, but since I would like to get better control of the data access I've started to "encapsulate" the data interface, so that access to the Plucker data (record header, paragraph headers, and paragraph data) must be done through a new interface. The only thing the "user" of this interface will know about is the handle to the record with the Plucker data. It is still possible to access the data directly, but I advice against it. I guess I'm about 60% finished. Anyway, as an initial test that the rendering and data access really are "separated" I made a few changes on the data access side and lo and behold the viewer can now render normal DOC documents ;-) It's far from perfect, but considering the few changes I had to make (return the uncompressed DOC text and "simulate" the Plucker header data) it works quite well... I have also found (and fixed) a couple of bugs in the bookmark handling and the new italic font support. The bug in the italic font support was that the pointer was used before the check to see if it was NULL and the bug in the bookmark handling was that a handle was locked, but never unlocked. /Mike ___ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
