Skip to content

tex, string, and separator options for units#1447

Open
Alex-Jordan wants to merge 1 commit into
openwebwork:PG-2.21from
Alex-Jordan:unitsDisplay
Open

tex, string, and separator options for units#1447
Alex-Jordan wants to merge 1 commit into
openwebwork:PG-2.21from
Alex-Jordan:unitsDisplay

Conversation

@Alex-Jordan

Copy link
Copy Markdown
Contributor

This implements one of the suggestions from @dpvc in #1437, and replaces that pull request.

  • Units defined in Units.pm can have string, tex, string_separator, and tex_separator properties.
  • All aliases for a unit will carry over these properties. To demonstrate what to do when this is unwanted, I moved micron to be a named unit instead of an alias.
  • The string property is used when the unit or its aliases are printed as a string.
  • The string property needs to use a string that can actually be printed in hardcopy. There is a comment about this in the file above where the big units hash is defined.
  • Since a unit may be interpolated as part of an argument to Compute(), make sure that any all string properties are also unit names.
  • The tex property is used when the unit or its aliases are printed as tex.
  • The tex_separator property are only used when the unit is not part of a larger fractional unit, and the unit is the first unit following a number. Otherwise a space is used, as has been the case. For example, 180° and 180° s, but 180 s ° (except as tex).
  • The string_separator property is similar, except it is also used even when there is a larger fractional unit. For example, 180°/s.
  • Only deg is using tex_separator and string_separator, with each set to the empty string. I considered doing this with degF and degC, but Google tells me there should be a space for those units for scientific publications.
  • contextUnits.pl was adding aliases for L (liter, liters, litre, and litres). It was cleaner to move those over to Units.pm. If there was a reason they were not already in Units.pm, I could move them back.

One thing that could still be improved, is that for string production, the spaces that are used in between numbers and units (when string_separator is not set), or between units and units should be nonbreaking spaces. I tried things that I though should work, but did not work for one reason or another. So that can be addressed in some future PR.

Try the problem from #1437 for some basic testing. Although you may want to also try with some more complicated units that have unit products and quotients.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant