<div><div>Thanks Troy,</div><div><br></div><div>If the order of filters has wider scope than the 3 filters already mentioned in this thread, why is only one ordering requirement noted in the wiki page for .conf files?<br></div><div><br></div><div><a href="https://wiki.crosswire.org/DevTools:conf_Files#Elements_required_for_proper_rendering">https://wiki.crosswire.org/DevTools:conf_Files#Elements_required_for_proper_rendering</a><br></div></div><div><br></div><div>It's not good to say so little about ordering, if what Troy just wrote is indeed the case.<br></div><div><br></div><div>Admittedly, we do say this <span style="background-color:rgb(255, 255, 255)"><span style="color:rgb(37, 37, 37)"><span style="font-family:sans-serif"><span style="font-size:14px">before the table goes on to list the legacy filters</span></span></span></span>:</div><div>"<span style="background-color:rgb(255, 255, 255)"><span style="color:rgb(37, 37, 37)"><span style="font-family:sans-serif"><span style="font-size:14px">These filters are applied in the order that they are listed in the conf. Some filters are dependent on each other for certain features - e.g. cross-references in notes require both the OSISFootnotes and the OSISScriprefs filters enabled."</span></span></span></span><br></div><div><br></div><div>Best regards,<br></div><div class="protonmail_signature_block"><div class="protonmail_signature_block-user"><div><br></div><div>David<br></div></div><div><br></div><div class="protonmail_signature_block-proton">Sent with <a href="https://protonmail.com" target="_blank">ProtonMail</a> Secure Email.<br></div></div><div><br></div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> On Tuesday, 7 July 2020 13:38, Troy A. Griffitts <scribe@crosswire.org> wrote:<br></div><div> <br></div><blockquote class="protonmail_quote" type="cite"><div>While I sympathize with your position, SWORD filters have always been applied in the order they are specified in the .conf file and many have order dependencies. SWORD filters are like UNIX piped commands. Order matters.<br></div><div><br></div><div>Some SWORD filter authors have used inter-dependencies and we don't have a complex system of "dependsOn" properties in the filter-set so each might know of any filters which needs to run before itself, with a manager working it all out. In fact, it is conceivable that, as with UNIX pipes, different ordering might be desired for different circumstances. Filters in SWORD are simply snippets of code which conform to a SAX processing model and are dynamically configured to be executed in whatever order is specified. The way these dependencies are specified is by order in the .conf file.<br></div><div><br></div><div>I really do sympathise with your position, Karl, and in practice, there is typically only a few order dependencies which exist. The alternative is to either remove these filter interdependencies altogether, or else to build the aforementioned "dependsOn" framework so a filter can specify its dependencies which need to run first, and then build the logic to organize all the specified dependencies for each specific filter pipeline and establish an order based on these, and then to change the principle that order in a .conf file is no longer a programmatic declaration of processing order.<br></div><div><br></div><div>Troy<br></div><div><br></div><div><br></div><div><br></div><div class="gmail_quote"><div>On July 7, 2020 4:02:17 AM GMT+02:00, Karl Kleinpaste <karl@kleinpaste.org> wrote:<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="moz-cite-prefix">On 7/6/20 9:12 PM, Troy A. Griffitts
wrote:<br></div><blockquote type="cite">edit
your morphgnt.conf file and reorder the options<br></blockquote><div><span style="font-family:FreeSerif"><br>I'm here to argue that, if order of GlobalFilterOption choices
matters, it's the job of the engine to enforce the correct order,
internally, regardless of their textual appearance order in .conf.<br> <br> I don't think I need to provide any reasoning for this argument,
because it's true by inspection: To claim otherwise is to claim
that every single module creator must be aware of required
ordering choices of a conceptually unordered list of features.</span></div></blockquote></div><div><br></div><div>-- <br></div><div>Sent from my Android device with K-9 Mail. Please excuse my brevity. <br></div></blockquote><div><br></div>