Text/Font position

Michif

Hi,

In my experiment, I draw single letters/symbols in the center of the screen and alternate between them and a fixation dot. I noticed that while the fixation dot is nicely centered, the symbols/letters are not (always). For instance, a capital O or a + sign are, but a small x and a - are not. They appear slightly below the center of the screen. Keyword center is always on default (True) and x and y coordinates are the same between all stimuli (0,0). Is this because text/fonts are drawn as a picture with a dedicated area large enough to fit capitalized as well as small letters?
Either way, is there a way to make sure they are always properly centered without messing around with the x,y coordinates?

Thanks,
Michel

sebastiaan

Hi Michel,

Is this because text/fonts are drawn as a picture with a dedicated area large enough to fit capitalized as well as small letters?

Not exactly, I think, but it must have something to do with the bounding box that is determined by the font renderer (which works in mysterious ways).

This would be a good moment to try the prerelease of 3.2, which uses an entirely different way to render text, and which should not suffer from this issue. If you try this, could you let me know how this works out?

• http://osdoc.cogsci.nl/3.2

Cheers!
Sebastiaan

Michif

Hey Sebastiaan,

I just tested it with the latest release I could find (opensesame_3.2.0a10-py2.7-win32-1) but could not get it to work. I am getting a bunch of other errors that do not seem to have anything to do with the issue at hand.

For example, this:
exception type: AttributeError
exception message: 'str' object has no attribute 'copy'

With:
var.dispSearch.copy(var.dispBlank)

---

And this:

File "C:\OSPrerelease\opensesame_3.2.0a10-py2.7-win32-1\lib\site-packages\libopensesame\inline_script.py", line 81, in prepare
    self.experiment.python_workspace._exec(self.cprepare)
  File "C:\OSPrerelease\opensesame_3.2.0a10-py2.7-win32-1\lib\site-packages\libopensesame\python_workspace.py", line 173, in _exec
    exec(bytecode, self._globals)
  Inline script, line 102, in <module>
  File "C:\OSPrerelease\opensesame_3.2.0a10-py2.7-win32-1\lib\site-packages\openexp\_canvas\canvas.py", line 1080, in text
    **style_args)
  File "C:\OSPrerelease\opensesame_3.2.0a10-py2.7-win32-1\lib\site-packages\openexp\_canvas\canvas.py", line 409, in __iadd__
    self['stim%d' % self._stimnr] = element
  File "C:\OSPrerelease\opensesame_3.2.0a10-py2.7-win32-1\lib\site-packages\openexp\_canvas\canvas.py", line 347, in __setitem__
    value = value.construct(self)
  File "C:\OSPrerelease\opensesame_3.2.0a10-py2.7-win32-1\lib\site-packages\openexp\canvas_elements.py", line 37, in construct
    return cls(canvas, *self._args, **self._kwargs)
  File "C:\OSPrerelease\opensesame_3.2.0a10-py2.7-win32-1\lib\site-packages\openexp\_canvas\_richtext\richtext.py", line 59, in __init__
    Element.__init__(self, canvas, **properties)
  File "C:\OSPrerelease\opensesame_3.2.0a10-py2.7-win32-1\lib\site-packages\openexp\_canvas\_element\element.py", line 62, in __init__
    self.prepare()
  File "C:\OSPrerelease\opensesame_3.2.0a10-py2.7-win32-1\lib\site-packages\openexp\_canvas\_richtext\psycho.py", line 30, in prepare
    im = self._to_pil()
  File "C:\OSPrerelease\opensesame_3.2.0a10-py2.7-win32-1\lib\site-packages\openexp\_canvas\_richtext\richtext.py", line 157, in _to_pil
    im = Image.fromqimage(self._to_qimage())
  File "C:\OSPrerelease\opensesame_3.2.0a10-py2.7-win32-1\lib\site-packages\openexp\_canvas\_richtext\richtext.py", line 144, in _to_qimage
    t = self._to_qgraphicstextitem()
  File "C:\OSPrerelease\opensesame_3.2.0a10-py2.7-win32-1\lib\site-packages\openexp\_canvas\_richtext\richtext.py", line 118, in _to_qgraphicstextitem
    t.setDefaultTextColor(QColor(self.color.colorspec))
TypeError: arguments did not match any overloaded call:
  QColor(Qt.GlobalColor): argument 1 has unexpected type 'tuple'
  QColor(int): too many arguments
  QColor(QRgba64): argument 1 has unexpected type 'tuple'
  QColor(Any): argument 1 has unexpected type 'tuple'
  QColor(): argument 1 has unexpected type 'tuple'

After this line:
path_template = var.get_file('stimuli_out/'+var.cond_category+'//'+str(var.exemplarTemplate)+'.bmp')

So, at least with this build, I cannot test it out yet

Michel

Michif

As a side note: I am having issues with presenting images loaded in like above but only with the expyriment and legacy backend, not with psychopy. However, OS does not throw an error, it just does not present the images, while it does so when using the psychopy backend. I am gonna test whether that has anything to do with the specific images or format. If not, I'll create another thread for this issue.

Edit: Not sure whether that is a general issue or somehow related to the pictures I use but everything works fine when converting my .bmp pictures into .jpgs.

eduard

I can confirm that expyriment and legacy refuse to display .bmps when using the canvas functions, whereas psychopy works. (And .jpgs work as well with all backends)

sebastiaan

Thanks for testing, guys! Once I'm back in Groningen, I'll fix these issue and build a new prerelease. (Assuming that they're easy to fix, but I assume so.)

Michif

Just for clarification: the issue with the images was not specific to the latest prerelease version but already an issue on the latest stable version. I assume that it is really specific to the pictures. Eduard and I observed that other .bmps seem to work.
The errors posted in my second post however are specific to the prereleases.

sebastiaan

Hi Michel,

Regarding the first error, resulting from:

var.dispSearch.copy(var.dispBlank)

Without more context, this strikes me as a problem with your script: var.dispSearch is a str object, whereas you seem to be assuming that it's a canvas. Or is there something more?

Regarding the second error:

TypeError: arguments did not match any overloaded call:

This seems to come from a call to canvas.text(). Is that possible? What exactly triggers the error?

Cheers!
Sebastiaan

Michif

Hey Sebastiaan,

Regarding the first error:
I don't think it is a string variable. When checking their types they both show up as classes. Also, as mentioned, the same code works fine with the latest stable version.
I just noticed though that it might indeed become clearer if I send you the full error message. The second-last line suggests, as far as I understand it, that something fails in copying the to-be-copied canvas on the designated canvas.

File "C:\OSPrerelease\opensesame_3.2.0a10-py2.7-win32-1\lib\site-packages\libopensesame\inline_script.py", line 81, in prepare
    self.experiment.python_workspace._exec(self.cprepare)
  File "C:\OSPrerelease\opensesame_3.2.0a10-py2.7-win32-1\lib\site-packages\libopensesame\python_workspace.py", line 173, in _exec
    exec(bytecode, self._globals)
  Inline script, line 16, in <module>
  File "C:\OSPrerelease\opensesame_3.2.0a10-py2.7-win32-1\lib\site-packages\openexp\_canvas\canvas.py", line 672, in copy
    self._elements = [e.copy(self) for e in canvas._elements]
AttributeError: 'str' object has no attribute 'copy'

Regarding the second error:
I just checked and you're right. After removing all canvas.text calls from the script (and the copy call from error #1), it works fine. Do I take from this that you will also change the name/keywords of the text-drawing function or is this still a bug?
By the way, I just noticed that the error message now indicates exactly the line where the error occurs rather than the previous line as it did in the past (that's also the reason why I copied the wrong line in my previous post), is that new or did I miss something?

Cheers,
Michel

PS: If you want to take a look at the script, see my email to you from last week. It should still be on my google drive.

sebastiaan

Hi Michel,

As of 3.2.0a11, these issues should be resolved. Thanks for testing this.

By the way, I just noticed that the error message now indicates exactly the line where the error occurs rather than the previous line as it did in the past (that's also the reason why I copied the wrong line in my previous post), is that new or did I miss something?

That's new. The old behavior was of course unintended, and resulted from counting an invisible line that specifies the character encoding.

Cheers!
Sebastiaan