lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [lmi-commits] master e6009c1 5/5: Demote an assertion to a con


From: Greg Chicares
Subject: Re: [lmi] [lmi-commits] master e6009c1 5/5: Demote an assertion to a conditional
Date: Mon, 30 Jul 2018 22:02:19 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 2018-07-30 15:39, Vadim Zeitlin wrote:
> On Mon, 30 Jul 2018 15:29:11 +0000 Greg Chicares <address@hidden> wrote:
> 
> [... not having enough space for elastic columns ...]
> GC> If we want to treat that as a problem, then we need to specify a minimum
> GC> width for elastic columns. For a personal name, perhaps anything less
> GC> than five em might be considered inadequate. However, only one column is
> GC> elastic in practice--the group-quote "Participant"--and AFAIK the design
> GC> of group quotes is such that there's always room for a dozen or two
> GC> characters in that column.
> 
>  Yes, this is the case currently. But if it ever changes, I think it would
> be better if we/the users were notified about it in at least some way. So I
> think there should be a warning (not an error considering the explanation
> below) in case there is not enough space. Would you agree?

Sure: if requirements change such that this becomes a practical concern,
then we should reconsider this question. But until that happens, it's
hard to guess what the answer will be. Elastic columns are probably
useful only for strings like names and addresses that are of practically
unconstrained length, and even for personal names in illustrations we
have four different "minimum" lengths already:

/opt/lmi/src/lmi[0]$grep Insured1 *.mst |sed -e's/^[^{]*//' -e's/[^}]*$//'      
   
{{Insured1}}
{{Insured1Abbrev50}}
{{Insured1Abbrev30}}
{{Insured1Abbrev30}}
{{Insured1Abbrev140}}
{{Insured1Abbrev30}}

IOW, it's a valid theoretical question, but all possible answers are
just pragmatic compromises designed to fit particular circumstances.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]