[sword-devel] Problems with text rendering

[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
>>
>