Enable "pass-through" of filtered layout of embedded fields

originally from #335191: CCK fields formatting (support Image- and Filefield)

>>If linking is disabled, can it be made to look exactly as if it's local? Is all the formatting from the source preserved? Q3 What about links, e.g. inline html, actual link-type fields, Glossary module flags, do these all look and behave the same as in the original node?

>No, all formatting is removed since I use check_plain()/l() for security reasons and to avoid infinite referencing (imagine an embedded textfield embeds itself with a Linodef tag). If you think it is important to preserve certain formatting than open a separate issue and list the tags you need (HTML filter, flags etc). Coding that could take a while or is limited to a small amount of tags because I have to heed possible security flaws.

----
Again this may be (are probably) separate issues, but in general my feature request is:

Support links in the source node continuing to be links in the target.

These examples come immediately to mind, you're probably aware of more:

• "grandparent" Linodef internal links (alert on save for circular refs?)
• traditional
• links generated by Glossary module

Use case - software documentation site, different node types:

"GlossaryEntry" nodes: short definitions of specific term topics with "hard edges", with "for more detail" links to TopicTerm nodes, automatic synonym and related terms "see also" functionality offered by Glossary module.

"TopicTerm" nodes are more in depth, conceptual definition/overview/background information 1:1 with the GlossaryEntries

"HowTo" and "Snippet" nodes store procedural step-by-step and code examples respectively

"Link" nodes simply point to an off-site resource, no local content

"Narrative" nodes are used where the edges aren't clear, mixing conceptual and procedural, intersection topics

I'd like to use Linodef as follows: Glossary entries pull their title from the Title field and the definition from the CCK definition_field of the same-name Topic term node - only one place to edit everything about that term rather than having to keep the two in sync.

Other fields in the Topic term contain different levels of detail, perhaps simply "intro-overview" and "in-depth details". Perhaps some nodes of this type would pull in canonical Snippets as examples.

Narratives would [pull in | link to] overview or in-depth content from different Topic term nodes, [pull in | link to] relevant HowTo's, Links and/or Snippets as needed via Linodef's inline tags. Ideally the only "local text" actually stored in Narratives would be meta information and connective writing for flow, not substantive technical information.

The data from these four source node types would be referenced in many different Narratives, obvious advantages in re-use and only needing to be kept up to date in one place.

Each of these different node types could be navigated to and displayed independently, classified by audience, difficulty, software version, editorial review tags etc., and/or grouped/filtered by taxonomy, date, author, rated/voted on, access controlled.

With Glossary automatically tagging the terms as they're used in the content with links back to the canonical definitions.

This use case would require that the links referenced in Link nodes, the glossary tags etc. get pulled through as active links in the target Narrative nodes.

The way I see it your module has the potential to make Drupal a killer community documentation/authoring platform.

Thanks for considering my ideas (and just for taking the time to read them! :)