Description of the problem:
When using more expansive fonts, text is clipped. Using the Comforter typeface from Google Fonts (in this case converted from .ttf to .woff2, though I find the same clipping behavior when sourcing font files differently), a textStim with text set to “j” cuts of significant portions of the letter.
This is shown in the attached image, on the far left. In the center, horizontal clipping of a second textStim has been alleviated by adding characters to either side, ie setting the text to “.j.”. On the right, all clipping of the j is alleviated by setting the text to " . \n.j.\n . ", ie adding a line above and below, in addition.
I’ve found this clipping of textStim text to be consistent and robust, occurring with various different typefaces. Have others experienced this problem? Is there a way to prevent this clipping, without having to pad the text itself with superfluous characters? Thanks!
Thanks for the response! I’ve looked at that other thread before, and didn’t find it to be helpful I’m afraid.
In principle, yes padding with spaces seems to work. In practice, I fear having to do so would be an incredible burden.
For my use case we rely heavily on precise placement and sizing, and frequently consider a stimulus’ (tight) bounding box. Adding spaces changes the reported size of the stimulus. It’s possible we could try measuring without spaces then displaying with spaces for every stim, but it would be cumbersome and unwieldy.
Have others run into this problem? I’ll talk about the space-padding approach with my collaborators, but an actual fix is still very much desired – not being able to reliably draw text seems a pretty massive undocumented limitation.
When running online, a Textbox component is currently a HTML textarea - which comes with its own limitations, including this. We’re working on creating a custom JS class for fast and precise text rendering like we have in Python, but until then I think the best solution is just to add sufficient padding that letters don’t exceed the textbox bounds and then account for this padding in your positioning.
That’s exciting news! Thank you both for your help, we’ll use padding for now as you suggest.
P.S. I found the whitespace-padding to only inflate the size of the bounding box on webkit browsers (Safari (macOS), Chrome (iOS)). On Chrome, Firefox, Brave, etc (macOS) the bounding box remained tight to the non-whitespace characters.
component is currently a HTML