Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve handling of byCapital font sizing #329

Open
wants to merge 1 commit into
base: 2.0
Choose a base branch
from

Conversation

jneubrand
Copy link

  • When determining offsets, use metrics for the current font as opposed to the inherited one (and remove logging that may have been intended to debug this issue)
  • Instead of saving a raw percentage, assume that fonts have an offset within [0, 0.25] and a height within [0.5, 1].
    This will allow users to use more precise alignment values, as we skip saving 3 redundant bits in the inheritance BitField.
    These bounds should probably be cross-checked with common fonts.
    This may seem arbitrary, but note that the [0, 1] range isn't even enough for some fonts—for example, Zapfino would need an offset below zero.
    Having another bit or two of precision each would be great for large text. I don't feel qualified to judge the design decisions in BitEncodings, but this may be good to keep in mind for future changes (will widthFill/heightFill still exist, are 12 bits for spacingX needed…)

- When determining offsets, use metrics for the current font as opposed to the inherited one (and remove logging that may have been intended to debug this issue)
- Instead of saving a raw percentage, assume that fonts have an offset within [0, 0.25] and a height within [0.5, 1].
  This will allow users to use more precise alignment values, as we skip saving 3 redundant bits in the inheritance BitField.
  These bounds should probably be cross-checked with common fonts.
  This may seem arbitrary, but note that the [0, 1] range isn't even enough for some fonts—for example, Zapfino would need an offset below zero.
  Having another bit or two of precision each would be great for large text. I don't feel qualified to judge the design decisions in BitEncodings, but this may be good to keep in mind for future changes (will `widthFill`/`heightFill` still exist, are 12 bits for `spacingX` needed…)
@jneubrand
Copy link
Author

By the way, those magic 0.25em numbers could be removed and get us to this:

let
    topVal =
        offset

    bottomVal =
        (1 - offset) - height

    margin =
        String.fromFloat (negate topVal)
            ++ "em "
            ++ (String.fromInt spacingX ++ "0px ")
            ++ String.fromFloat (negate bottomVal)
            ++ "em"
in
Attr.style "margin"
    margin
    :: Attr.style "padding" "0 calc((1/32) * 1em) 0 0px"
    :: Attr.style "overflow" "visible"
    :: attrs

—note the overflow: visible. This way, the hitbox isn't larger than necessary :)

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