One of my core research activities is the transcription and translation of audio-recorded texts. As a result, ELAN has been an indispensable part of my workflow for many years now. So first, I want to thank you for making this powerful tool available free of cost.
Second, I face a chronic problem when I work in Transcription mode: the last line (or even two!) of text in the cells is often not visible, or only partially visible. The more columns I am using at once (I often use four columns), the more pervasive the problem is. Can this problem be resolved?
FYI, I primarily use ELAN on a MacBook Pro laptop and I am currently using ELAN 6.3.
Thank you for your kind words. As to the problem, I’m not immediately able to reproduce it. I assume the problem mainly (or only?) concerns the cell that is being edited, or also ‘static’ cells? I can see that it usually takes the time of a few keystrokes on a new line before the cell height is updated, but then it seems alright.
The height calculation is based on the font and font size (and other properties), could it be the problem is related to the font in use? I’m just guessing here what might be the case.
The problem occurs in both active and static cells. In other words, it occurs both while I am actively transcribing and while I am proofreading my work.
My font choices are guided by the need to use IPA characters and diacritics, i.e., I need to use a Unicode font. I am presently using Noto Sans Light (a free Google font). I used to use Charis SIL, but this problem was much worse with Charis.
I am usually working in 24pt font because (a) I am using a laptop with a small screen, (b) I am nearsighted, and (c) I need to be able to distinguish among the IPA characters and diacritics. FYI, if I switch to smaller fonts sizes, the problem is lessened but still exists.
Here is a screen shot illustrating the problem in my workspace:
Thanks very much!
Thank you for the additional information. I can now reproduce the problem, e.g. with Charis SIL.
This will help us in trying to find a solution for this problem!
Hi Chris! I have this problem as well. It occurs with all font types and whether or not I am using diacritics vs diacritic-free ASCII.
My solution is to click on the bar between the Transcription Mode table and the video/waveform viewer so that I get a double-headed cursor, then drag to resize the video.
This forces the table part of the view to resize as well. That resolves the line breaking problem for the cell that my cursor is in, but only for that one, not for any others that are being cut off. So for example, line 1160 is fixed in the second view below, but line 1156 is still cut off.
Before resizing the viewer & table:
In the meantime I have been looking into the relevant code and the problem indeed doesn’t seem to be the font in use (or at least not only).
The text of an annotation, usually a single string of text without line breaks, is automatically line wrapped by the text field. The calculation of the required height of each row (our code) is based on the required width of the entire string (given the font and font size etc.) and the width of the column (i.e. of the cell), but without knowledge of the actual number of lines after line wrapping. This leads to unpredictable mismatches.
At least, that’s my preliminary conclusion, hopefully we can fix/improve this for the next release.