[sword-devel] Problems with text rendering

[Martin Gruner]

Troy,  

just wanted to add that your suggestion sounds very good to me.

mg

Am Dienstag, 13. Oktober 2009 19:32:18 schrieb Troy A. Griffitts:
> Yeah Martin,
> 
> This seems like a problem with the concept of running an EXTERNAL buffer
> through a modules RenderFilters:
> 
> module->RenderText(externalBuffer);
> 
> as opposed to the usual use of simply rendering the module at its
> current position:
> 
> module->RenderText();
> 
> Currently this resets the INTERNAL entryAttributes when rendering the
> EXTERNAL buffer.
> 
> My thinking is that in this mode we should not touch the internal entry
> attributes.  This is easy to fix and we can still remain binary compatible.
> 
> But I don't think this is the ultimate solutions.  This does not address
> the issue of obtaining entry attributes from the supplied external buffer.
> 
> If we offer the service of rendering an external buffer through a given
> module's render filters, then we should completely support rendering
> external info.  We should probably add an optional parameter that can be
> passed with externalBuf, something like externalEntryAttributes, so you
> can obtain attributes from any external buffer you ask to be rendered.
> 
> I've added the check to bypass entryAttribute processing in SVN.  This
> should make your code work as is.  Let me know.
> 
> 	-Troy.
> 
> Martin Gruner wrote:
> > Hi Troy,
> >
> > thank you for the hint. I see a problem though: The code that I mentioned
> > is the actual OSIS filter that is being used when we render text. Now in
> > a different method, I want to access the entry attributes just like
> > usual, but the filter already destroyed them.
> >
> >     key->key(keyname);
> >     key->renderedText(); //force entryAttributes
> >
> >     const char* note =
> >         module->module()->getEntryAttributes()
> >         ["Footnote"][swordFootnote.toLatin1().data()]["body"].c_str();
> >
> > Since the entry attributes are not stored in a key, but in the module, I
> > guess that filters may not be allowed to call renderText() at all, since
> > it destroys the EntryAttribute structure of the module. Is my
> > understanding correct?
> >
> > I just saw that renderText() has a parameter bool render. I will try
> > turning this off to see if this works around the problem, but in my
> > opinion there is still a design problem.
> >
> > What do you think?
> >
> > mg
> >
> > Am Montag, 12. Oktober 2009 18:40:32 schrieb Troy A. Griffitts:
> >> Dear Martin,
> >>
> >> I believe the BPBible or Xiphos guys ran into this same problem a little
> >> while back.  I think, after talking about it, the best solution was to
> >> simply grab a copy on the stack, near the top of your method, and let it
> >> go out of scope after the filter completes.
> >>
> >> AttributeTypeList entryAttributes = myModule->getEntryAttributes();
> >>
> >> Hope this helps.
> >>
> >> 	-Troy.
> >>
> >> Martin Gruner wrote:
> >>> Hi Troy,
> >>>
> >>> may I ask for your help with a rendering issue we are experiencing? I
> >>> believe the code once came from you (simplerender.patch).
> >>>
> >>> It is in our OSIS filter descendant, where crossref notes are
> >>> processed.
> >>>
> >>> <code>
> >>>                if (type == "crossReference") { //note containing cross
> >>> references
> >>>                     myUserData->inCrossrefNote = true;
> >>>                     myUserData->noteType = BT_UserData::CrossReference;
> >>>
> >>>                     buf.append("<span class=\"crossreference\">");
> >>>                     sword::SWBuf footnoteNumber =
> >>> tag.getAttribute("swordFootnote");
> >>>                     sword::SWBuf footnoteBody = myUserData-
> >>>
> >>>> entryAttributes["Footnote"][footnoteNumber]["body"];
> >>>
> >>>                     buf += myModule->RenderText(footnoteBody);
> >>>                 }
> >>> </code>
> >>>
> >>> Now the problem seems to be the final RenderText() call. It destroys
> >>> the EntryAttributes structure when processing the footnote body.
> >>>
> >>> Can you give me a hint how I can work around that? Is there a better,
> >>> preferred method?
> >>>
> >>> Thanks and regards, Martin
> >>
> >> _______________________________________________
> >> sword-devel mailing list: sword-devel at crosswire.org
> >> http://www.crosswire.org/mailman/listinfo/sword-devel
> >> Instructions to unsubscribe/change your settings at above page
> 
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
> 

-- 

Bauplan des Lebens - längst im Gen entdeckt!
Die Wissenschaft ist stolz: Sie hat's gecheckt.
Nun ist der Bauplan als Beweis beliebt,
dass es den Architekten gar nicht gibt.

Wolf Rahn