The foundation for your business
Fork me on GitHub
[ledgersmb-devel] Re: LaTeX::Encode versus TeX::Encode
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ledgersmb-devel] Re: LaTeX::Encode versus TeX::Encode

Hi Chris,

On Wed, Apr 22, 2020 at 5:23 PM Chris Bennett <..hidden..> wrote:
On Sun, Apr 19, 2020 at 07:20:44PM +0200, Erik Huelsmann wrote:
> Hi Chris,
> Template::Plugin::Latex has an encoding routine which we're *not* using to
> encode data before being passed to (Xe)LaTeX.
> We're contemplating simplifying places in our codebase and one of the
> changes would be to use the built-in latex_encode. Do you have any
> recollection with respect to the choice for TeX::Encode and whether we
> should be fine to move to "latex_encode" all these years later?

I don't see any problems.

That's perfect! How did you test for problems? I mean, which characters? Which patch did you apply to our code base to make sure Tex::Encode wasn't active and the "latex_encode" filter *was*?
Right now I'm waiting for ports lock to pass.
Then I will push in new stuff. Just let me know once a decision is made
and I will make that reflect what needs to go in.

Yup. We're working on developing tests within the LedgerSMB project to assure we're making the right decisions; however, if you already did that, that would be double work?
We just traveled permanently from Washington state back to Texas, so I'm
a little out of touch with the ports mailing list (next list I'm going
to check).

Ports lock is done to stabilize everything in order to release 6.7

Simplifying is usually a good idea. :-}

Definitely! And that's why we're always looking to reduce the number of dependencies. But not at the expense of good functionality.

I'll ping what I have already submitted and send in more modules once
things are unlocked.

Travel safely!





http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
devel mailing list -- ..hidden..
To unsubscribe send an email to ..hidden..