The MetaRecord data type is bloated, and since any given document stores a
lot of meta-records (is it one per record viewed, or one per record in
history?), a good deal of RAM can get used up by a large
document. Moreover, to keep on doing things the way they have been done,
I would have to bloat the MetaRecord data type a bit more by adding
Char userFontName[ dmDBNameLength ] to handle named fonts loaded in from
prcs. (I already did this in my local copy and it works very nicely,
but it does use up RAM.)
So, here is my adventurous proposal to save RAM and allow for some added
functionality, albeit with a slight loss (see end).
Proposal:
1. Remove from MetaRecord all or many of the following items:
UInt16 depth;
FontModeType font;
Int16 maxExtentX;
Int16 maxExtentY;
ToolbarType toolbar;
ScrollbarType scrollbar;
Int16 lineSpacing;
Int16 paragraphSpacing;
2. Put all of these in a new internal metarecord, _RENDERING_DATA.
3. Whenever depth, font, maxExtentX, toolbar, scrollbar, lineSpacing
and paragraphSpacing change, go through all of the metarecords in the
document and set height=0. This will force redraws.
4. Whenever maxExtentY changes, do nothing like this. Instead, whenever
a record is loaded up for viewing, check that we are not in a position
where the current position needs to be adjusted due to a maxExtentY
change. (The issue is that if maxExtentY is increased while the
current position is close to the end, the record needs to be scrolled
back a little. Currently this is being done when the silkscreen
is resized, given the code I committed yesterday.)
5. When loading in the document, check that the _RENDERING_DATA record
matches the prefs. If not, then unless the difference is in
maxExtentY alone, do step 3.
6. Remove the testing on a record-by-record basis for change of these
things.
Gains:
1. 16 bytes less per record. For those of us who deal with files that
have hundreds of records, this can make some difference. The gain
is even larger once the user font code gets added.
2. It will be easy to implement a new feature: The ability to set
different fonts for different documents. This is particularly
useful if one has different encodings in different documents, but
also useful if some documents work better with small fonts and others
with large ones. Basically, one just sets
Prefs()->individualDocumentFonts = true, and then _RENDERING_DATA
is used to set the corresponding items in Prefs() whenever the
document is loaded, and Prefs() gets expanded to have items like
defaultFontMode. I suppose this could be implemented in the current
arrangement by just going through all the records and ensuring they
have the same meta data when one changes the data for a document, but
that is messy. (Suggestions for other solutions are most welcome.)
Loss:
There would be only one loss if one did this. Currently, if I am
viewing one record, change the font, and change it back, there is
no need to re-render the other records, and Plucker keeps one's
place in the other records if they are accessed via the history.
This could be fixed, too, if one were ambitious. Perhaps the history
could keep track of the text offset rather than the y-position.
But I don't think this is a big deal. It is only relevant if one
changes a font and changes it back.
--
Dr. Alexander R. Pruss || e-mail: [EMAIL PROTECTED]
Philosophy Department || online papers and home page:
Georgetown University || www.georgetown.edu/faculty/ap85
Washington, DC 20057 ||
U.S.A. ||
-----------------------------------------------------------------------------
"Philosophiam discimus non ut tantum sciamus, sed ut boni efficiamur."
- Paul of Worczyn (1424)
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
