Clarify units of measurement for zones, surface, etc. #73
Comments
ahankinson
added
imported
Priority: Medium
Type: Bug
|
From kep...@edirom.de on June 20, 2012 09:02:03 In att.measurement we define @Unit for this very purpose. att.measurement is used by elements like , , (among others). The @ulx style attributes are defined in att.coordinated. As att.measurement doesn't define other attributes, what about making att.coordinated a member of att.measurement? Everything with those coordinates would inherit @-unit as well… |
|
From andrew.hankinson on June 20, 2012 12:56:00 Copy and Paste Perry's e-mail (to keep track of the discussion): It wouldn't be a huge problem in this particular case, but in general many layers of inheritance make me a little nervous -- it sets up dependencies that have to be resolved/disentangled later. So, as an alternative, I suggest that we make the members of att.coordinated (currently, there are only 3) members of att.measurement too. However, I'm not sure this completely addresses Andrew's need. If I understand correctly, Andrew was also looking for a list of appropriate values. |
|
From andrew.hankinson on June 20, 2012 13:35:21 I don't know if this is a big deal, but that means that we can only ever have one @-unit on an element. So if we wanted to mix our units -- say pixels and points in different attributes on the same element, we can't. Doing it the HTML way seems to get around that by specifying the unit type in the field itself. This might not be an issue -- I don't know. But Perry is right, it would also be nice to have an open-ended enumerated list of default measurement types and maybe even record a decision about the default unit if it is not specified. I vote for pixels, but there may be compelling reasons to vote for centimetres or points... |
|
From lxpu...@gmail.com on June 22, 2012 04:07:00 I would vote for points, which seems to be the more 'neutral' to me - does it make any sense? |
|
From kep...@edirom.de on June 22, 2012 04:16:22 I wouldn't specify a default unit in the Guidelines, especially not points. Points are a typograhic unit, and there is almost no natural connection to music typesetting. If we want a natural unit, I'd prefer centimeters (or maybe inches). But then again, one should be able to specify a resolution for digital units (expressed in dpi). But again, all that seems like an unnecessary hassle, I would just suggest some units and leave it to the encoder to specify the one he's using. We just can't stop people from doing dumb things with MEI, no matter how hard we try… |
|
From lxpu...@gmail.com on June 22, 2012 04:21:53 Good, we have three votes with three different opinions ;-) A fourth one? |
|
From raffaele...@gmail.com on June 22, 2012 04:27:46 For facsimile elements, TEI always assumes pixels. Those points are supposed to refer to digital images, there are other elements to deal with real manuscript objects and I definitely see the value of keeping things separated. So I'd keep pixels. Other elements that express some form of measurement (tei:space, tei:measure, etc.) there is a dedicate class att.dimensions http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.dimensions.html It allows to specify any @-unit (there's a recommended list). |
|
From pd...@virginia.edu on June 22, 2012 08:15:23 Let's adopt the TEI method. I'll add an open value list for @-unit that includes in = inches Any others that should be on the list? Since it's an open list additional values can be used ad hoc. Can we "bump up" this feature request to bug status and include it in 2012? |
|
From andrew.hankinson on June 22, 2012 10:44:48 Sure, I think we can bump this to a bug report. It's not added functionality, just clarifying existing functionality. The only other unit for "absolute" values specified in the CSS3 documentation is 'picas.' It might also be useful to include the following in a note or documentation: ‘cm’ centimeters |
|
From pd...@virginia.edu on June 22, 2012 10:49:17 Labels: -Type-Enhancement -Milestone-Release2013 Type-Bug Milestone-ReleaseNext |
|
From pd...@virginia.edu on June 22, 2012 11:52:19 Status: Started |
|
From pd...@virginia.edu on June 22, 2012 14:55:56 Owner: pd...@virginia.edu |
|
From lxpu...@gmail.com on June 25, 2012 01:22:19 Why would you define the 'size' of a pixel? This is resolution dependent, and it will always be 1/96 of 1in. |
|
From pd...@virginia.edu on June 25, 2012 06:02:47 We're not talking about defining the size of a pixel, only units of a measurement. '103' doesn't tell you anything until you say it's pixels you're counting and not picas. Are you objecting to documenting the definition of inches, pixels, etc.? |
|
From lxpu...@gmail.com on June 25, 2012 06:07:16 Yes, I am objecting the definitions. The definition for 1in is OK. But for pixels, I think it is wrong to say that 1px is 1/96th of a 1in - it can be, but not necessary. I don't know about points and picas. |
|
From andrew.hankinson on June 25, 2012 06:18:23 Before changing it, it's perhaps helpful to look at the CSS3 documentation for this. It's specifying a 'reference pixel,' http://www.w3.org/TR/css3-values/#lengths They admit that the reason for the reference pixel definition is because this differs from earlier CSS definitions and changing it would break older content. Since displays are starting to vary widely in pixel densities (all of the 'retina' displays from Apple have different pixel densities) and more are likely on their way, it might be nice to have the pixel defined in terms of a physical measurement -- we can use 1/96th of an inch, or we could use 0.26mm. |
|
From lxpu...@gmail.com on June 25, 2012 06:53:21 OK, this make sense for CSS. If we have a physical measurement defined by default for a pixel, I think it would be useful to be able to specify a custom resolution. For example, if the surface is in a image at 300dpi, then we need to be able to specify it. Is there something like this in TEI? I did not see anything in the att.dimensions class |
|
From andrew.hankinson on June 25, 2012 07:39:37 I don't think we do need to specify it. A 2000 x 3000 pixel image will always be 2000 x 3000 pixels, regardless of the DPI. If I'm on a "standard" 1/96in per pixel monitor, I will need at 21" monitor to display it in full width. If I'm on a "retina" display at 1/326in per pixel, I will only need a 7" monitor to display it at full width. It's up to image software to render and figure out if it wants to honour the DPI tag in an image or not. Usually they don't unless you're working in a DTP application; in which case it will handle the pixels / inch conversion for displaying on the users' monitor anyway. |
|
From lxpu...@gmail.com on June 25, 2012 08:03:25 I find it problematic. Specifying pixels is not only for display it on monitors - and assuming that the default pixel size is at 96dpi is specific to monitors. If you want to render (e.g., print it) what is given in the encoding at its real size, you would need to look up at the dpi within the image file even if you don't necessary what to display the image. And if you don't and assume 96dpi, it will appear mon the 3 time larger that the original on your print. So if we specify a default dpi (which is what is done with the definition), we need to provide a way to overwrite it. |
|
From pd...@virginia.edu on June 27, 2012 13:06:10 This issue was closed by revision r580 . Status: Fixed |
|
From lxpu...@gmail.com on June 28, 2012 01:46:55 Sorry to insist, but I am not very confortable with the fixed definition of the pixel size. CSS (and monitors) is only one case where dpi are involved. As I tried to suggest (sorry for the typos), either we do not say anything about it, or we provide a way to redefine it. Why not adding a @-resolution in order to be able to overwrite it? |
|
From kep...@edirom.de on June 28, 2012 03:27:34 I agree with Laurent, the current solution has very nasty side effects. If trying to measure a 300dpi image, one could think the image is more than three times as large as it is. If we want to keep this sentence in the documentation, we definitely need @res / @-resolution as well. Removing the fixed definition is at least equally good. As there seems to be need for further discussion, I reopen the ticket. Status: Started |
|
From pd...@virginia.edu on June 29, 2012 14:41:31 How about for the time being we simply remove the documentation in att.measurement; that is, the stuff in parentheses? This doesn't solve the problem of defining the size of a pixel, but it doesn't supply an "incorrect" definition either. It simply bypasses the problem. Also, I'll make the list in att.measurement "semi" and remove my klugey att.unitized class. |
|
From lxpu...@gmail.com on June 30, 2012 04:50:02 Sounds good to me. We can keep in mind that we can one day add a @-res, but I don't think it is necessary right know. |
|
From pd...@virginia.edu on July 19, 2012 11:51:52 This issue was closed by revision r602 . Status: Fixed |
From andrew.hankinson on June 20, 2012 09:53:31
Currently we assume that a number in the @ulx, @-uly, etc. is expressed in pixels. It would be nice to support either:
a) specifying the unit of measurement in the field, e.g., ulx="100px", "uly=20cm", etc.
or
b) specifying the unit of measurement globally or contextually (all child tag inherit a unit specification) , e.g., "
Original issue: http://code.google.com/p/music-encoding/issues/detail?id=73
The text was updated successfully, but these errors were encountered: