<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p style="margin-top:0;margin-bottom:0">Hi there,</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">I'm a little late to the conversation, but wondering if pixels are the best for <img> width within device screens or for the printed page.</p>
<p style="margin-top:0;margin-bottom:0">I often use vw and vh, viewport width and viewport height:</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0"><a href="https://css-tricks.com/fun-viewport-units/" class="OWAAutoLink" id="LPlnk318715" previewremoved="true">https://css-tricks.com/fun-viewport-units/</a></p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">and here ...</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0"><a href="https://css-tricks.com/full-width-containers-limited-width-parents/" class="OWAAutoLink" id="LPlnk450115" previewremoved="true">https://css-tricks.com/full-width-containers-limited-width-parents/</a></p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">... but of course the point we want to get to is not having to resort to media queries, or specific stylesheets for print and screen outputs.</p>
<p style="margin-top:0;margin-bottom:0">I'm really getting into CSS Grid:</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0"><a href="https://css-tricks.com/snippets/css/complete-guide-grid/" class="OWAAutoLink" id="LPlnk382058" previewremoved="true">https://css-tricks.com/snippets/css/complete-guide-grid/</a></p>
<p style="margin-top:0;margin-bottom:0"><a href="http://jensimmons.com/post/feb-27-2017/learn-css-grid" class="OWAAutoLink" id="LPlnk972795" previewremoved="true">http://jensimmons.com/post/feb-27-2017/learn-css-grid</a></p>
<br>
<p style="margin-top:0;margin-bottom:0">... but this would be too long a stride out at this point, so I suggest viewport widths:</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0"></p>
<div>img {</div>
<div>       border-style: none;</div>
<div>       border: 0;</div>
<div>       box-sizing: border-box;</div>
<div>       min-width: 80vw;     /* 80% of the screen or page width, or whatever % you prefer */</div>
<div>       max-width: 95vw;<span style="font-family: Calibri, Helvetica, sans-serif, Helvetica, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">    /* again,</span><span style="font-family: Calibri, Helvetica, sans-serif, Helvetica, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;"> whatever
 % you prefer </span><span style="font-family: Calibri, Helvetica, sans-serif, Helvetica, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">*/</span></div>
<div>       height: auto;        </div>
<div>}</div>
<div><br>
</div>
<p></p>
<p style="margin-top:0;margin-bottom:0">I'd like to work with anyone on this so please keep me in the loop.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">Thanks, Martin</p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Discuss <discuss-bounces@lists.flossmanuals.net> on behalf of M R <matrobnew@hotmail.com><br>
<b>Sent:</b> Tuesday, 13 February 2018 10:29:46 a.m.<br>
<b>To:</b> discuss@lists.flossmanuals.net<br>
<b>Subject:</b> Re: [FM Discuss] issues with Kdenlive manual images</font>
<div> </div>
</div>
<style type="text/css" style="display:none">
<!--
p
        {margin-top:0;
        margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p style="margin-top:0; margin-bottom:0">Hi Mick:</p>
<p style="margin-top:0; margin-bottom:0"><br>
</p>
<p style="margin-top:0; margin-bottom:0">Well, for my part, I thank you for being so gracious in responding to my often-polemical screeds.  That's kind of how I  process what I learn -- and working on the Floss manuals has been a huge learning experience for
 me -- but some of it should probably just be saved for my cat.  She's used to it.</p>
<p style="margin-top:0; margin-bottom:0"><br>
</p>
<p style="margin-top:0; margin-bottom:0">The image-width constraint has been a challenge, but a productive one, as I start working through the how-to chapters of the Shotcut manual.   I'm managing so far.  I'm sure there are all kinds of feature benefits in
 moving to Booktype 2.x, but I'm sure it's a hassle too.</p>
<p style="margin-top:0; margin-bottom:0"><br>
</p>
<p style="margin-top:0; margin-bottom:0">As far as changing the global css override for image width in our current Booktype: seems like a lot of factors to consider there.  One, how do modern browsers process the css implemented there -- I don't know nearly
 as much about that as some people in this community.  Most modern websites are designed to scale gracefully down to very small screen sizes, without scrolling -- especially in the era of tablet and mobile browsing.  But that's typically about how different
 page elements flow around each other, rather than how a specific large image is handled.  Still, I know that all my browsers (IE, Chrome, Firefox) will automatically scale down a large image to fit my window, in nearly all cases, unlesss I force them to show
 me the image full-size.  </p>
<p style="margin-top:0; margin-bottom:0"><br>
</p>
<p style="margin-top:0; margin-bottom:0">I don't think we're anywhere close, with Booktype 1.6, to being able to produce html content that's in any sense mobile-ready; so really this is a question of how many people are actually accessing the Floss manuals
 on desktops and laptops with windows set to less than a 800 px or 700 px resolution.  Maybe we could do a survey?  And similarly, how many people are using the print-friendly format (since that would probably remain the real constraint).</p>
<p style="margin-top:0; margin-bottom:0"><br>
</p>
<p style="margin-top:0; margin-bottom:0">best,</p>
<p style="margin-top:0; margin-bottom:0"><br>
</p>
<p style="margin-top:0; margin-bottom:0">Matt</p>
<br>
<br>
<div style="color:rgb(0,0,0)">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Discuss <discuss-bounces@lists.flossmanuals.net> on behalf of Mick Chesterman <M.Chesterman@mmu.ac.uk><br>
<b>Sent:</b> Monday, February 12, 2018 3:16 AM<br>
<b>To:</b> discuss@lists.flossmanuals.net<br>
<b>Subject:</b> Re: [FM Discuss] issues with Kdenlive manual images</font>
<div> </div>
</div>
<div dir="ltr" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hi Matt,</p>
<p><br>
</p>
<p>Thanks for these thoughtful responses. I can see your point about the advantage of video tutorials for these kinds of complex situations where there are a lot of moving parts.
</p>
<p>And you make a good case for looking at different situations and using doc tools based on the most appropriate response.
<br>
</p>
<p><br>
</p>
<p>As far as the screen limit, at the moment, the css override is the following;</p>
<p>img {<br>
       border-style:none;<br>
       max-width:800px;<br>
       height: auto;        <br>
}</p>
<p><br>
</p>
<p>I would be very up for changing that to increase if we can work out a way of the image size scaling down if people's windows are smaller.</p>
<p><br>
</p>
<p>This has been helpful for me to start up conversations to get moved to booktype 2 as well. 
<br>
</p>
<p><br>
</p>
<p>Thanks</p>
<p>Mick<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p> <br>
</p>
<p><br>
</p>
<div id="x_x_Signature">
<div style="font-family:Tahoma; font-size:13px">
<p class="x_x_MsoNormal"><span style="font-size:10.0pt; font-family:"Arial",sans-serif; color:#323E4F"></span><font color="#000000" face="Calibri, sans-serif" style="font-size:11pt"><b>From:</b> Discuss <discuss-bounces@lists.flossmanuals.net> on behalf of
 M R <matrobnew@hotmail.com></font><br>
</p>
</div>
</div>
<div dir="ltr" style="color:rgb(33,33,33)">
<div id="x_x_divRplyFwdMsg" dir="ltr"><font color="#000000" face="Calibri, sans-serif" style="font-size:11pt"><b>Sent:</b> 10 February 2018 21:07<br>
<b>To:</b> discuss@lists.flossmanuals.net<br>
<b>Subject:</b> Re: [FM Discuss] issues with Kdenlive manual images</font>
<div> </div>
</div>
<div>
<div id="x_x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p style="margin-top:0; margin-bottom:0">Mick:</p>
<p style="margin-top:0; margin-bottom:0"><br>
</p>
<p style="margin-top:0; margin-bottom:0">I just sent a version of this response with a doc attachment, but the listserve is balking at the size of the attachment as it has multiple screenshots, so here is just the text of my response repeated.  Perhaps the
 moderator-machine will let my first version with the attachment through in time.  Meanwhile:</p>
<p style="margin-top:0; margin-bottom:0"></p>
<p style="font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; font-size:16px">
I think you raise a valid point, and codifying screenshot guidelines sounds like a good idea; but I also think it just depends utterly on what kind of authoring or editing tool (and what kind of media) we're talking about.  Generally speaking, the more complex
 the media (or multimedia) being edited or authored, the more likely it is that a UI surface will need to have multiple panes/panels/windows showing different kinds of information, but that really need to be viewed simultaneously (more or less) to get a whole
 picture of what you're doing in a given operation.   And very little software UI design today, for such editors, assumes that users will confine themselves to anything like an 800 px-wide screen resolution.</p>
<p style="font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; font-size:16px">
Let's consider some concrete examples.  Audio is in some ways the simplest medium, and so with a tool like Audacity, you're for the most part just working in tracks on a linear timeline, so showing just part of that timeline in a screenshot will generally suffice
 to put across your operation.  And a simple text editor, of course, can pretty much be sized however you want it, within reason.  With code-editors it depends on how feature-rich the UI is.  Static image editors and draw tools, same thing: I think our Inkscape
 manual does an amazing job of working with probably too-confined real estate.  Photoshop or Gimp would also be a challenge, though I can imagine it.  Something like Powerpoint or comparable slide-deck tools is already pushing the limits for small-screen editing,
 even of a 'static' product, since slide-decks really aren't static anyway.</p>
<p style="font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; font-size:16px">
For a video editor, that's already much more complex as you have a linear timeline plus a video display, plus typically other panes with important property information.  So far in the new Shotcut manual I've just shown just portions of each of these, which
 is fine for a walk-through of the different panels but will be a real constraint when I get to the actual 'how-to' chapters.  But I'll do my best.</p>
<p style="font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; font-size:16px">
For a tool to author any kind of multimedia/interactive eLearning material (e.g. Articulate Storyline, Adobe Captivate), you can very rarely get away with seeing just 700-800 px of real estate at once.  Or Flash (now reborn as Animate), or really just about
 any Adobe-model multimedia authoring product.  For 3D modeling and game-building tools, not a chance.  It's true that you will still want to draw your reader's/viewer's attention to different parts of the UI, to understand what they're about, but to get a
 sense of real-time operations you need to see the whole.  In these cases there is no such thing as "the most relevant part of the screen" -- it's all relevant.  This is really why video software tutorials almost always show the full software UI, taking up
 most or all of the presenter's desktop, and are typically now shot in high-resolution and meant to be viewed wide-screen or full-screen too.     </p>
<p style="font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; font-size:16px">
I've already indicated other reasons why I think a text-and-screenshot document for a tool like Blender or Unity is pretty pointless.  I'd extend that to many of the other tools I've mentioned here.  Shotcut is probably pushing it, though at least in video
 editing the number of <i>moving</i>parts is still (somewhat) limited.  Still, if there were simply more decent video tutorials extant for Shotcut, I wouldn't consider it worthwhile to write an FM manual for it.  And setting the moving-parts argument aside,
 if I were designing a BookType-style platform now, I'd never put in a 700 px hardcoded limit for images, regardless of the target medium, even print.  </p>
<p style="font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; font-size:16px">
Attached (in the original, currently-embargoed version) is a doc with me putting my $$ or effort where my mouth is regarding tutorials for a tool like Unity3D.  One can still find book-length text-and-screenshot manuals for Unity too, but to my mind they are
 entirely pointless.  For Shotcut, though, the effort still seems worthwhile, at least at this stage in the process.  Ask me again in another few weeks.</p>
<p style="font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; font-size:16px">
Best,</p>
<p style="font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; font-size:16px">
<br>
</p>
<p style="font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; font-size:16px">
Matt</p>
<div><br>
</div>
<br>
<p></p>
<br>
<br>
<div style="color:rgb(0,0,0)">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_x_divRplyFwdMsg" dir="ltr"><font color="#000000" face="Calibri, sans-serif" style="font-size:11pt"><b>From:</b> Discuss <discuss-bounces@lists.flossmanuals.net> on behalf of mick@flossmanuals.net <mick@flossmanuals.net><br>
<b>Sent:</b> Saturday, February 10, 2018 5:57 AM<br>
<b>To:</b> discuss@lists.flossmanuals.net<br>
<b>Subject:</b> Re: [FM Discuss] issues with Kdenlive manual images</font>
<div> </div>
</div>
<div class="x_x_BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="x_x_PlainText"><br>
<br>
On 09/02/18 20:16, M R wrote:<br>
> 00 px is a pretty draconian limit for modern screenshots, though, as<br>
> no one in their right might would use most of these editing tools at<br>
> that width.  I get that the print version needs some kind of image<br>
> width limit.  One would think that the "Constrain Proportions"<br>
> function would at least, you know, constrain proportions if the image<br>
> exceeded that limit, and simply show a smaller overall screenshot. <br>
> But I can't get that to work in the editor: it seems to always take<br>
> the actual height but constain the width.  No doubt why they fixed it<br>
> in 2.2...<br>
<br>
As Rosalind pointed out, I does seem to do that for the published<br>
version. But I have seen squished images in the editor too.<br>
<br>
So maybe we can work on a guideline for images width based on what they<br>
look like when they are outputted to pdf. 800px for me seems about right<br>
as above that it is hard to see what you want users to look at.<br>
<br>
For me although the challenge of drawing the attention to the most<br>
relevant part of the screen.<br>
<br>
Thanks<br>
Mick<br>
_______________________________________________<br>
Discuss mailing list<br>
Discuss@lists.flossmanuals.net<br>
<a href="http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net" id="LPlnk428840">http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net</a> - you can unsubscribe here
<div id="LPBorder_GT_15182966616010.08774375264512213" style="margin-bottom:20px; overflow:auto; width:100%; text-indent:0px">
<table id="LPContainer_15182966615970.5139390542661277" cellspacing="0" style="width:90%; background-color:rgb(255,255,255); overflow:auto; padding-top:20px; padding-bottom:20px; margin-top:20px; border-top:1px dotted rgb(200,200,200); border-bottom:1px dotted rgb(200,200,200)">
<tbody>
<tr valign="top" style="border-spacing:0px">
<td id="x_x_TextCell_15182966615980.1372464797864208" colspan="2" style="vertical-align:top; padding:0px; display:table-cell">
<div id="LPRemovePreviewContainer_15182966615980.9175548908119062"></div>
<div id="LPTitle_15182966615980.5009115045003227" style="top:0px; color:rgb(0,120,215); font-weight:400; font-size:21px; font-family:wf_segoe-ui_light,"Segoe UI Light","Segoe WP Light","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; line-height:21px">
<a id="LPUrlAnchor_15182966615990.8408991922679212" href="http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net" target="_blank" style="text-decoration:none">Discuss Info Page - lists.flossmanuals.net</a></div>
<div id="LPMetadata_15182966615990.31631360409658393" style="margin:10px 0px 16px; color:rgb(102,102,102); font-weight:400; font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; font-size:14px; line-height:14px">
lists.flossmanuals.net</div>
<div id="LPDescription_15182966616000.9902189375666932" style="display:block; color:rgb(102,102,102); font-weight:400; font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; font-size:14px; line-height:20px; max-height:100px; overflow:hidden">
Discuss anything about floss manuals - its aims, what it does, how it does it, what it could do, and how it can be better. To see the collection of prior postings to ...</div>
</td>
</tr>
</tbody>
</table>
</div>
<br>
<br>
</div>
</span></font></div>
</div>
</div>
</div>
</div>
"Before acting on this email or opening any attachments you should read the Manchester Metropolitan University email disclaimer available on its website http://www.mmu.ac.uk/emaildisclaimer "
</div>
</div>
</div>
</div>
</body>
</html>