Hi,
On Wed, Jan 25, 2017 at 9:35 PM, Máirín Duffy <duffy@...43...> wrote:
On 01/25/2017 03:18 PM, Máirín Duffy wrote:
Yep, I did this in the extended info. I think the options get too long if it's in the radio options. Do you think this is ok?
Goofed the link here - thanks to Bryan for pointing that out - http://i.imgur.com/YF7MCWl.png
I maintain two extensions for making board game components, as I posted about earlier on the list. In particular the countersheetsextension (https://github.com/lifelike/countersheetsextension) is affected by this. There is probably someone that uses it to make graphics for a screen, but the vast majority (everyone I heard from) wants to make sheets of cardboard counters or cards to print. Sometimes the sheets will be cut by machines, so of course the coordinates have to be correct.
With that background, looking at the drafts and original dialog I still am not sure what I should choose (and what I need to inform the users of the extension to choose!). Obviously the goal for anyone would be that if they work on say a card-game in Inkscape 0.91, upgrade to 0.92 (and upgrades to a later version of my extension that supports 0.92) and keep working on the same game, they want sheets printed to look identical. Same location relative to the page, same size and layout of all the text and graphics seen on each card. Pixel-coordinates is not likely to be on anyone's mind at all, as long as all the real-world coordinates and sizes seen in the GUI (and in the printed result) stay correct.
I am pretty sure that the correct option for us will be "intended for physical output" and hopefully everyone will figure that out. Although it might distract many to see the strong bold text saying "choose if unsure", coupled with that option being the default. Kind of inviting to click the "wrong" one? But then I am confused about the two sub-options. Why are they needed? It sounds as if scaling individual elements is the correct choice always. Does the other (default?) option exist only because Inkscape currently has some bugs? So in a future 0.92.x or later version the bad option might be removed, because the correct individual scaling will work properly? But by that time it might be too late I guess because many will have already chosen to convert their files using the inferior method, and it will be difficult to repair? In that case it might be better to stay on 0.91 until this has been solved?
This concern is of course no different from those making physical games without my extension, or most other users only interested in what the printed results look like. It just happens to be the only group of users I am familiar with.