As far as I can tell, the only place in the Publish workspace that has ancestor numbering is the Ahnentafel report. At the time of my first post, I had thought that it was available on more items, but I was confusing it with the other program I use.
At any rate, not to get too deep into a discussion of coding, but calling an external function to calculate the Ancestral Lines number (rather than the Ahnentafel number) on one report is trivial. At the worst, another function might have to be created for Ahnentafel numbering, but that's very easily done.
As for the descendant numbering and adding an upside-down version of Ancestral Lines, I should think that it would be equally simple. No doubt there are already functions for the existing numbering systems supported, because those reports already support choices. This would require little alteration to call a different function. Or, if it's done up front before it's extracted from the database (perhaps from a cached table for faster performance), then that's just the matter of changing the queries to the database. With a variety of approaches, I just don't see the huge time sink in this idea.
(Of course, that doesn't address the value of the Ancestral Lines numbering system. As it can express half-siblings, it's more capable than Ahnentafel or Ahnentafel derived systems. It just comes at the price of being extraordinarily cryptic for the uninitiated.)
At any rate, not to get too deep into a discussion of coding, but calling an external function to calculate the Ancestral Lines number (rather than the Ahnentafel number) on one report is trivial. At the worst, another function might have to be created for Ahnentafel numbering, but that's very easily done.
As for the descendant numbering and adding an upside-down version of Ancestral Lines, I should think that it would be equally simple. No doubt there are already functions for the existing numbering systems supported, because those reports already support choices. This would require little alteration to call a different function. Or, if it's done up front before it's extracted from the database (perhaps from a cached table for faster performance), then that's just the matter of changing the queries to the database. With a variety of approaches, I just don't see the huge time sink in this idea.
(Of course, that doesn't address the value of the Ancestral Lines numbering system. As it can express half-siblings, it's more capable than Ahnentafel or Ahnentafel derived systems. It just comes at the price of being extraordinarily cryptic for the uninitiated.)