From rclord at seaserpent.com Fri Feb 2 18:44:44 2018 From: rclord at seaserpent.com (Rosalind Lord) Date: Fri, 2 Feb 2018 18:44:44 -0800 Subject: [FM Discuss] updated section on recording configuration using Audacity in Mac OS X In-Reply-To: References: <1515752050448.97437@mmu.ac.uk> <1515755527327.19255@mmu.ac.uk> <50b2b311872f45d88a6aa37a64aa1f95@BFEX02.ad.mmu.ac.uk> <30e660dc-8d6f-4492-3516-c937e892db20@goos-habermann.de> <05554b58f2e347d693e00972ebdaf56b@BFEX02.ad.mmu.ac.uk> <0D3D2E08-94C6-4E53-91B9-52977C967F7D@seaserpent.com> <8d26e9a5-6492-46e5-f9d5-b4d0cbbf894e@goos-habermann.de> <9048b70d-97e9-17ce-e713-1f8984c69e26@goos-habermann.de> <6b389df7-c5fb-4f7a-ab0b-8f81c9b9a720@flossmanuals.net> Message-ID: Hi all: I just updated the section on recording configuration using Audacity on the Mac. You no longer need to configure any preferences. The preferences in Audacity 2.2.1 are now completely different than they were in earlier versions. Once Audacity 2.2.1 is installed in OS X, it will automatically be connected to your Mac's built-in microphone, and you can start recording in Audacity 2.2.1 right away. Have a great weekend, - Rosalind > On Jan 29, 2018, at 2:08 AM, M R wrote: > > thanks, Rosalind -- that would be great. > > Matt > > > From: Discuss > on behalf of Rosalind Lord > > Sent: Monday, January 29, 2018 2:17 AM > To: discuss at lists.flossmanuals.net > Subject: Re: [FM Discuss] next steps on Audacity book > > Matt, I?ll be happy to look over and/or edit the Mac config section in the Recording chapter. > > - Rosalind > >> On Jan 27, 2018, at 12:04 PM, M R > wrote: >> >> Mick (et al): >> >> All great stuff on your changes and review. Thanks for addressing the table issue in the Menu chapter. And the image max-width: I didn't even know that could be adjusted. I had just ended up making all of my screenshots smaller so as to get around that distortion issue. >> >> I think the ePub book proof looks really good. The pdf one doesn't seem to handle page-breaks very gracefully (among other issues), but it doesn't appear that there's a way to handle that at the level of the content-edit platform itself. Nor does the pdf seem to auto-generate a table of contents, which is a more significant failing -- but again these must be issues common to all Floss manuals in pdf. Or maybe there are settings you can fiddle with specific to generating PDFs on the platform. >> >> In the "Recording" chapter, yes I do still see my bracketed comment/query about whether that Mac-specific config stuff was still applicable to 2.x. Certainly we should remove the comment. But it's still an open question to me whether we should remove any or all of the original Mac config info that follows too--and I think that can only be settled via experimentation with a Mac. So Rosalind or another Mac person will have to address that. I think we decided in general that we would *not* preserve in this manual any info pertaining only to 1.x versions of Audacity, at least unless it was clearly flagged as such. >> >> Mick, as to your final suggestion about moving the chapters around, I certainly see the logic insofar as the Tutorial chapters are much more 'fun'/interesting to read (as they were to re-write). However, there is probably a more compelling logic to walking through the UI systematically before diving into those tutorials, since at many points they embed the assumption that you know where to find a given menu item, or they only use the quickest shorthand (like "Go to Edit > Tracks > Split Track") rather than giving you screenshots or any more detailed guidance on the UI. Further, at least in the ePub format where the menu is readily accessible, it's easy enough for the reader to skip straight to the tutorials if they choose to. That is another reason, though, why having a TOC (and ideally a clickable one) is pretty vital for the PDF version too. >> >> Anyway, thanks again for your work on this. If Rosalind can take a look at that Mac config stuff in the Record chapter, and if you know any magic you can do with the PDF-generate settings, then I think we're good to go for this iteration. >> >> Matt >> >> >> >> >> From: Discuss > on behalf of mick at flossmanuals.net > >> Sent: Saturday, January 27, 2018 4:09 AM >> To: discuss at lists.flossmanuals.net >> Subject: Re: [FM Discuss] next steps on Audacity book >> >> Hi there, >> >> I've had a chance to review this, Great work! >> >> Just one thing I think needs to be looked at >> There's still a comment visible on Mac recording questions - it does seem like this might need some simplification here >> Here are some thing I did. >> I've added 10px padding to table which I think helps. >> I've removed a legacy issue about linux recording issues. >> I've increased the max-width of image display to 800px , height:Auto to help with some image distortions. This seems to be fine on screen but doesn't take for the pdf, >> >> I've generated pdfs and epubs here for testing too. >> http://objavi.booktype.pro:80/data/books/audacity-en-2018.01.27-11.59.46.epub >> http://objavi.booktype.pro:80/data/books/audacity-en-2018.01.27-12.00.12.pdf >> >> >> More general feedback is that the chapter under tutorials look great. Good work. >> I would be tempted to move them right to the front of the book as a more task focused start, and to move installation and the explanations of the file menus in the appendix. >> That way the reader can get started trying things out right away. That's just a suggestion tho. >> >> >> Thanks >> Mick >> >> >> On 26/01/18 00:14, M R wrote: >>> Hi Martin: >>> >>> It does need proofreading, as its been almost completely rewritten as part of the update to 2.x. Mick has offered to do that this weekend, but a pair of fresh eyes probably wouldn't hurt either--as long as Katou is reasonably expeditious, since we are trying to wrap this up and get it republished so it can actually get to users. Localization is another and certainly important issue: my only working language (at the level of something like this manual) is English, and if someone wanted to translate the revision into other languages that would be a good thing, but also I think a separate project. Finally, I don't know if Katou has prior expertise with Audacity, but if so, you could mention that this manual is far from comprehensive, esp in the 'How to' or tutorial chapters, and there's always opportunity to add in more chapters with additional functionality. Which would, again, though, be something we'd want to address in a further iteration of the manual, not the imminent one. >>> >>> Matt >>> >>> >>> From: Discuss on behalf of Martin Kean >>> Sent: Thursday, January 25, 2018 4:01 PM >>> To: discuss at lists.flossmanuals.net >>> Subject: Re: [FM Discuss] next steps on Audacity book >>> >>> Hi Maren and Matt, >>> >>> I've just added Katou as a user, who is interested in proofreading and localisation, along with writing and editing. Does the Audacity manual need proofreading? >>> >>> Username: katou >>> Email: katou at live.it >>> >>> Thanks, Martin >>> From: Discuss on behalf of Maren Hachmann >>> Sent: Friday, 26 January 2018 3:35:58 a.m. >>> To: discuss at lists.flossmanuals.net >>> Subject: Re: [FM Discuss] next steps on Audacity book >>> >>> Yes, same URL - maybe something with your browser cache not refreshing? >>> >>> Maren >>> >>> Am 25.01.2018 um 09:04 schrieb Mick Chesterman: >>> > Great but strange. >>> > >>> > What URL are you testing >>> > I was testing here where it is still 12px for me on Firefox >>> > http://write.flossmanuals.net/start-with-inkscape/test-chapter-for-trying-out-styling/ >>> /chapter: Test-Chapter-For-Trying-Out-Styling / Start with ... >>> write.flossmanuals.net >>> Test Chapter (for trying out styling) This chapter is meant for trying out how to best style the book. This is a keyboard shortcut: Ctrl + A. This is a special note ... >>> >>> >>> > >>> > Thanks >>> > Mick >>> >> -----Original Message----- >>> >> From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net ] On Behalf Of >>> >> Maren Hachmann >>> >> Sent: 24 January 2018 21:34 >>> >> To: discuss at lists.flossmanuals.net >>> >> Subject: Re: [FM Discuss] next steps on Audacity book >>> >> >>> >> I don't see any problems, it seemst to have worked just fine, see screenshot. >>> >> >>> >> Thank you very much, Mick! >>> >> >>> >> Maren >>> >> >>> >> Am 24.01.2018 um 21:33 schrieb Rosalind Lord: >>> >>> Mick, would you like me to help with this? I have lots of experience >>> >>> coding HTML and CSS. >>> >>> >>> >>> - Rosalind >>> >>> >>> >>>> On Jan 23, 2018, at 11:59 PM, Mick Chesterman >>> >> >>> >>>> >> wrote: >>> >>>> >>> >>>> Hi there, >>> >>>> >>> >>>> I've added an override but it doesn't seem to have taken. >>> >>>> Can you start a ticket here and let's try to solve this together. >>> >>>> https://gitlab.com/flossmanuals/fm_booktype/issues >>> >>>> >>> >>>> Thanks >>> >>>> Mick >>> >>>> >>> >>>>> -----Original Message----- >>> >>>>> From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net ] On >>> >>>>> Behalf Of Maren Hachmann >>> >>>>> Sent: 23 January 2018 23:16 >>> >>>>> To: discuss at lists.flossmanuals.net >>> >>>>> > >>> >>>>> Subject: Re: [FM Discuss] next steps on Audacity book >>> >>>>> >>> >>>>> Piggy-backing, as I've got a CSS change request, too: >>> >>>>> The font size for ordered / unordered lists is too small by default >>> >>>>> (12px instead of 13px for all other text in a manual), because the >>> >>>>> lists are not wrapped in paragraphs (which have a font size of 13), >>> >>>>> and inherit the body font size. >>> >>>>> >>> >>>>> As this doesn't only affect the Inkscape guide, but all books on the >>> >>>>> site, and all lists in them, it needs to be fixed on server level. >>> >>>>> Fixing each list individually, and thus having inline styles that >>> >>>>> might mess up exporting would be possible, but tedious and ugly. >>> >>>>> >>> >>>>> Could you please set the font size for lists inside the content area >>> >>>>> to 13, too? >>> >>>>> >>> >>>>> CSS to modify, starting line 1574 in booki.css: >>> >>>>> >>> >>>>> #full-view-content p, #bookcontent p, #bookcontent ol, #bookcontent >>> >>>>> ul { >>> >>>>> font-size: 13px; >>> >>>>> line-height: 140%; >>> >>>>> margin: 1em 0; >>> >>>>> padding: 0; >>> >>>>> } >>> >>>>> >>> >>>>> Thanks, >>> >>>>> Maren >>> >>>>> >>> >>>>> Am 23.01.2018 um 04:31 schrieb M R: >>> >>>>>> Thanks, Mick -- the weekend would be fine with me. Maybe best to >>> >>>>>> have someone who has some familiarity with the old book, and in >>> >>>>>> general with the folkways of FM. >>> >>>>>> >>> >>>>>> >>> >>>>>> I may have mentioned this before, but there's one specific >>> >>>>>> formatting issue I'd like you (or whoever reviews) to consider, >>> >>>>>> aside from whatever else comes up. In the Menu Bar chapter there >>> >>>>>> is extensive use of tables to hold the menu information. As I did >>> >>>>>> wherever possible, here I preserved the formatting from the >>> >>>>>> original book, where these tables were set to zero cell padding and >>> >>>>>> no border. This worked well enough in the original version, when >>> >>>>>> each cell entry was at most a single sentence in length, and it >>> >>>>>> resulted in a nice clean design. However, Audacity 2.x's much more >>> >>>>>> extensive use of submenus forced me to make considerably longer >>> >>>>>> entries in some of those table cells, and I'm not certain how >>> >>>>>> readable the end result is for some tables. I think the solution >>> >>>>>> would be pretty straightforward: either adding a bit of cell padding to >>> >> each table, or adding a narrow border. >>> >>>>>> But I didn't want to go either way without consultation. I don't >>> >>>>>> think this issue afflicts any chapter beyond the Menu Bar ch. >>> >>>>>> >>> >>>>>> >>> >>>>>> Matt >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> ------------------------------------------------------------------- >>> >>>>>> ----- >>> >>>>>> *From:* Discuss >>> >>>>>> >> on behalf of Mick >>> >>>>>> Chesterman >>> >> >> >>> >>>>>> *Sent:* Monday, January 22, 2018 1:00 AM >>> >>>>>> *To:* discuss at lists.flossmanuals.net >>> >>>>>> > >>> >>>>>> *Subject:* Re: [FM Discuss] next steps on Audacity book >>> >>>>>> >>> >>>>>> >>> >>>>>> HI there, >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> This sounds good. Can anyone step forward to have a look over the >>> >>>>>> Audacity manual before we do a pdf and epub print for the front page? >>> >>>>>> >>> >>>>>> I can do it at the weekend if not. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> Thanks >>> >>>>>> >>> >>>>>> Mick >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> Mick Chesterman >>> >>>>>> >>> >>>>>> Educational Innovation and Enterprise Tutor & >>> >>>>>> >>> >>>>>> EdLab Project Developer >>> >>>>>> >>> >>>>>> Department of Childhood, Youth and Education Studies. >>> >>>>>> >>> >>>>>> Manchester Metropolitan University >>> >>>>>> >>> >>>>>> Web: http://edlab.org.uk > / Twitter: >>> >>>>>> @EdLabMMU >>> >>>>>> >>> >>>>>> EdLab MMU - Exploring Educational Innovation and ... >>> >>>>> > >>> >>>>>> edlab.org.uk > >>> >>>>>> Exploring Educational Innovation and Enterprise in Education - >>> >>>>>> Creatively generating projects rooted in community engagement and >>> >>>>>> student experience. >>> >>>>>> >>> >>>>>> >>> >>>>>> Phone: 0161 2472060 >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> /Please note: My working days are Monday, Tuesday, Wednesday and >>> >>>>> Thursday/ >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> *From:*Discuss [mailto:discuss-bounces at lists.flossmanuals.net ] *On >>> >>>>>> Behalf Of *M R >>> >>>>>> *Sent:* 18 January 2018 21:05 >>> >>>>>> *To:* discuss at lists.flossmanuals.net >>> >>>>>> > >>> >>>>>> *Subject:* Re: [FM Discuss] next steps on Audacity book >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> Mick: >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> It looks to me like other folks have finished adding in their >>> >>>>>> pieces to the non-Windows sections of the manual re-write, so >>> >>>>>> whenever you get a chance at some quality control (just because I >>> >>>>>> assume that someone needs to, who hasn't been a >>> >>>>>> writer-contributor), then we can wrap this up and get it published, >>> >>>>>> to start helping whoever out there might actually want to use it. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> Actually, I suppose someone else could handle the review too -- not >>> >>>>>> sure what the protocol is here. But I just wanted to make sure >>> >>>>>> this stays in the queue as a near-term task. I assume we all have >>> >>>>>> day jobs ?(I'm a college professor so I was just on holiday break >>> >>>>>> -- that's why I could find 50 hrs or so to do the bulk of the rewrite). >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> thanks, >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> Matt >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> ------------------------------------------------------------------- >>> >>>>>> ----- >>> >>>>>> >>> >>>>>> *From:*Discuss >>> >>>>>> > >>> >>>>>> >> on behalf of Mick >>> >>>>>> Chesterman >>> >> > >>> >>>>> >> >>> >>>>>> *Sent:* Friday, January 12, 2018 4:12 AM >>> >>>>>> *To:* discuss at lists.flossmanuals.net >>> >>>>>> > >>> >>>>> > >>> >>>>>> *Subject:* Re: [FM Discuss] next steps on Audacity book >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> To exit chapter titles you just double click into the title on the >>> >>>>>> chapter list screen. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> *From:*Discuss >>> >>>>>> > >>> >>>>>> >> on behalf of M R >>> >>>>>> > >>> >>>>>> >> >>> >>>>>> >>> >>>>>> *Sent:*12 January 2018 10:55 >>> >>>>>> *To:* discuss at lists.flossmanuals.net >>> >>>>>> > >>> >>>>> > >>> >>>>>> *Subject:* Re: [FM Discuss] next steps on Audacity book >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> I actually wanted to edit some of the other chapter TITLES a bit, >>> >>>>>> but couldn't figure out a way to do that. No big deal though, as >>> >>>>>> the current titles will serve. I did drag one entire chapter out >>> >>>>>> of the to-be-published structure and down to the bottom: that was >>> >>>>>> "MP3 INSTALLATION ON WINDOWS" bc it's no longer necessary to >>> >>>>>> install the >>> >>>>> LAME >>> >>>>>> MP3 codec separately. Just one of many ways that Audacity has >>> >>>>>> gotten more user-friendly over the years. >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> "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 " >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> Discuss mailing list >>> >>>>>> Discuss at lists.flossmanuals.net >>> >>>>>> > >>> >>>>>> http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net >>> >>>>>> - you can >>> >>>>> unsubscribe here >>> >>>>>> >>> >>>>> >>> >>>> >>> >>>> "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 " >>> >>>> _______________________________________________ >>> >>>> Discuss mailing list >>> >>>> Discuss at lists.flossmanuals.net >>> >>>> > >>> >>>> http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - >>> >>>> you can unsubscribe here >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Discuss mailing list >>> >>> Discuss at lists.flossmanuals.net >>> >>> http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - >>> >>> you can unsubscribe here >>> >>> >>> >> >>> > >>> > "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 " >>> > _______________________________________________ >>> > Discuss mailing list >>> > Discuss at lists.flossmanuals.net >>> > http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here >>> > >>> >>> >>> >>> >>> _______________________________________________ >>> Discuss mailing list >>> Discuss at lists.flossmanuals.net >>> http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here >> >> _______________________________________________ >> Discuss mailing list >> Discuss at lists.flossmanuals.net >> http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here > > Check out Sea Serpent Design's cards and gifts ? > > ... at Zazzle: > > New Year Clock Card ... at Redbubble: > > > > _______________________________________________ > Discuss mailing list > Discuss at lists.flossmanuals.net > http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Check out Sea Serpent Design's cards and gifts ? ... at Zazzle: Ladybug Hearts Card by rclord Dog King and Queen of Hearts by rclord ... at Redbubble: -------------- next part -------------- An HTML attachment was scrubbed... URL: From matrobnew at hotmail.com Fri Feb 2 20:27:08 2018 From: matrobnew at hotmail.com (M R) Date: Sat, 3 Feb 2018 04:27:08 +0000 Subject: [FM Discuss] updated section on recording configuration using Audacity in Mac OS X In-Reply-To: References: <1515752050448.97437@mmu.ac.uk> <1515755527327.19255@mmu.ac.uk> <50b2b311872f45d88a6aa37a64aa1f95@BFEX02.ad.mmu.ac.uk> <30e660dc-8d6f-4492-3516-c937e892db20@goos-habermann.de> <05554b58f2e347d693e00972ebdaf56b@BFEX02.ad.mmu.ac.uk> <0D3D2E08-94C6-4E53-91B9-52977C967F7D@seaserpent.com> <8d26e9a5-6492-46e5-f9d5-b4d0cbbf894e@goos-habermann.de> <9048b70d-97e9-17ce-e713-1f8984c69e26@goos-habermann.de> <6b389df7-c5fb-4f7a-ab0b-8f81c9b9a720@flossmanuals.net> , Message-ID: thanks a lot, Rosalind -- I suspected that was the case. So Mick, I think we might be clear to publish now, whenever you want to pull the trigger. best, Matt ________________________________ From: Discuss on behalf of Rosalind Lord Sent: Friday, February 2, 2018 7:44 PM To: discuss at lists.flossmanuals.net Subject: [FM Discuss] updated section on recording configuration using Audacity in Mac OS X Hi all: I just updated the section on recording configuration using Audacity on the Mac. You no longer need to configure any preferences. The preferences in Audacity 2.2.1 are now completely different than they were in earlier versions. Once Audacity 2.2.1 is installed in OS X, it will automatically be connected to your Mac's built-in microphone, and you can start recording in Audacity 2.2.1 right away. Have a great weekend, - Rosalind On Jan 29, 2018, at 2:08 AM, M R > wrote: thanks, Rosalind -- that would be great. Matt ________________________________ From: Discuss > on behalf of Rosalind Lord > Sent: Monday, January 29, 2018 2:17 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] next steps on Audacity book Matt, I?ll be happy to look over and/or edit the Mac config section in the Recording chapter. - Rosalind On Jan 27, 2018, at 12:04 PM, M R > wrote: Mick (et al): All great stuff on your changes and review. Thanks for addressing the table issue in the Menu chapter. And the image max-width: I didn't even know that could be adjusted. I had just ended up making all of my screenshots smaller so as to get around that distortion issue. I think the ePub book proof looks really good. The pdf one doesn't seem to handle page-breaks very gracefully (among other issues), but it doesn't appear that there's a way to handle that at the level of the content-edit platform itself. Nor does the pdf seem to auto-generate a table of contents, which is a more significant failing -- but again these must be issues common to all Floss manuals in pdf. Or maybe there are settings you can fiddle with specific to generating PDFs on the platform. In the "Recording" chapter, yes I do still see my bracketed comment/query about whether that Mac-specific config stuff was still applicable to 2.x. Certainly we should remove the comment. But it's still an open question to me whether we should remove any or all of the original Mac config info that follows too--and I think that can only be settled via experimentation with a Mac. So Rosalind or another Mac person will have to address that. I think we decided in general that we would *not* preserve in this manual any info pertaining only to 1.x versions of Audacity, at least unless it was clearly flagged as such. Mick, as to your final suggestion about moving the chapters around, I certainly see the logic insofar as the Tutorial chapters are much more 'fun'/interesting to read (as they were to re-write). However, there is probably a more compelling logic to walking through the UI systematically before diving into those tutorials, since at many points they embed the assumption that you know where to find a given menu item, or they only use the quickest shorthand (like "Go to Edit > Tracks > Split Track") rather than giving you screenshots or any more detailed guidance on the UI. Further, at least in the ePub format where the menu is readily accessible, it's easy enough for the reader to skip straight to the tutorials if they choose to. That is another reason, though, why having a TOC (and ideally a clickable one) is pretty vital for the PDF version too. Anyway, thanks again for your work on this. If Rosalind can take a look at that Mac config stuff in the Record chapter, and if you know any magic you can do with the PDF-generate settings, then I think we're good to go for this iteration. Matt ________________________________ From: Discuss > on behalf of mick at flossmanuals.net > Sent: Saturday, January 27, 2018 4:09 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] next steps on Audacity book Hi there, I've had a chance to review this, Great work! Just one thing I think needs to be looked at * There's still a comment visible on Mac recording questions - it does seem like this might need some simplification here Here are some thing I did. * I've added 10px padding to table which I think helps. * I've removed a legacy issue about linux recording issues. * I've increased the max-width of image display to 800px , height:Auto to help with some image distortions. This seems to be fine on screen but doesn't take for the pdf, I've generated pdfs and epubs here for testing too. http://objavi.booktype.pro:80/data/books/audacity-en-2018.01.27-11.59.46.epub http://objavi.booktype.pro:80/data/books/audacity-en-2018.01.27-12.00.12.pdf More general feedback is that the chapter under tutorials look great. Good work. I would be tempted to move them right to the front of the book as a more task focused start, and to move installation and the explanations of the file menus in the appendix. That way the reader can get started trying things out right away. That's just a suggestion tho. Thanks Mick On 26/01/18 00:14, M R wrote: Hi Martin: It does need proofreading, as its been almost completely rewritten as part of the update to 2.x. Mick has offered to do that this weekend, but a pair of fresh eyes probably wouldn't hurt either--as long as Katou is reasonably expeditious, since we are trying to wrap this up and get it republished so it can actually get to users. Localization is another and certainly important issue: my only working language (at the level of something like this manual) is English, and if someone wanted to translate the revision into other languages that would be a good thing, but also I think a separate project. Finally, I don't know if Katou has prior expertise with Audacity, but if so, you could mention that this manual is far from comprehensive, esp in the 'How to' or tutorial chapters, and there's always opportunity to add in more chapters with additional functionality. Which would, again, though, be something we'd want to address in a further iteration of the manual, not the imminent one. Matt ________________________________ From: Discuss on behalf of Martin Kean Sent: Thursday, January 25, 2018 4:01 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] next steps on Audacity book Hi Maren and Matt, I've just added Katou as a user, who is interested in proofreading and localisation, along with writing and editing. Does the Audacity manual need proofreading? Username: katou Email: katou at live.it Thanks, Martin ________________________________ From: Discuss on behalf of Maren Hachmann Sent: Friday, 26 January 2018 3:35:58 a.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] next steps on Audacity book Yes, same URL - maybe something with your browser cache not refreshing? Maren Am 25.01.2018 um 09:04 schrieb Mick Chesterman: > Great but strange. > > What URL are you testing > I was testing here where it is still 12px for me on Firefox > http://write.flossmanuals.net/start-with-inkscape/test-chapter-for-trying-out-styling/ /chapter: Test-Chapter-For-Trying-Out-Styling / Start with ... write.flossmanuals.net Test Chapter (for trying out styling) This chapter is meant for trying out how to best style the book. This is a keyboard shortcut: Ctrl + A. This is a special note ... > > Thanks > Mick >> -----Original Message----- >> From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of >> Maren Hachmann >> Sent: 24 January 2018 21:34 >> To: discuss at lists.flossmanuals.net >> Subject: Re: [FM Discuss] next steps on Audacity book >> >> I don't see any problems, it seemst to have worked just fine, see screenshot. >> >> Thank you very much, Mick! >> >> Maren >> >> Am 24.01.2018 um 21:33 schrieb Rosalind Lord: >>> Mick, would you like me to help with this? I have lots of experience >>> coding HTML and CSS. >>> >>> - Rosalind >>> >>>> On Jan 23, 2018, at 11:59 PM, Mick Chesterman >> >>>> > wrote: >>>> >>>> Hi there, >>>> >>>> I've added an override but it doesn't seem to have taken. >>>> Can you start a ticket here and let's try to solve this together. >>>> https://gitlab.com/flossmanuals/fm_booktype/issues >>>> >>>> Thanks >>>> Mick >>>> >>>>> -----Original Message----- >>>>> From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On >>>>> Behalf Of Maren Hachmann >>>>> Sent: 23 January 2018 23:16 >>>>> To: discuss at lists.flossmanuals.net >>>>> >>>>> Subject: Re: [FM Discuss] next steps on Audacity book >>>>> >>>>> Piggy-backing, as I've got a CSS change request, too: >>>>> The font size for ordered / unordered lists is too small by default >>>>> (12px instead of 13px for all other text in a manual), because the >>>>> lists are not wrapped in paragraphs (which have a font size of 13), >>>>> and inherit the body font size. >>>>> >>>>> As this doesn't only affect the Inkscape guide, but all books on the >>>>> site, and all lists in them, it needs to be fixed on server level. >>>>> Fixing each list individually, and thus having inline styles that >>>>> might mess up exporting would be possible, but tedious and ugly. >>>>> >>>>> Could you please set the font size for lists inside the content area >>>>> to 13, too? >>>>> >>>>> CSS to modify, starting line 1574 in booki.css: >>>>> >>>>> #full-view-content p, #bookcontent p, #bookcontent ol, #bookcontent >>>>> ul { >>>>> font-size: 13px; >>>>> line-height: 140%; >>>>> margin: 1em 0; >>>>> padding: 0; >>>>> } >>>>> >>>>> Thanks, >>>>> Maren >>>>> >>>>> Am 23.01.2018 um 04:31 schrieb M R: >>>>>> Thanks, Mick -- the weekend would be fine with me. Maybe best to >>>>>> have someone who has some familiarity with the old book, and in >>>>>> general with the folkways of FM. >>>>>> >>>>>> >>>>>> I may have mentioned this before, but there's one specific >>>>>> formatting issue I'd like you (or whoever reviews) to consider, >>>>>> aside from whatever else comes up. In the Menu Bar chapter there >>>>>> is extensive use of tables to hold the menu information. As I did >>>>>> wherever possible, here I preserved the formatting from the >>>>>> original book, where these tables were set to zero cell padding and >>>>>> no border. This worked well enough in the original version, when >>>>>> each cell entry was at most a single sentence in length, and it >>>>>> resulted in a nice clean design. However, Audacity 2.x's much more >>>>>> extensive use of submenus forced me to make considerably longer >>>>>> entries in some of those table cells, and I'm not certain how >>>>>> readable the end result is for some tables. I think the solution >>>>>> would be pretty straightforward: either adding a bit of cell padding to >> each table, or adding a narrow border. >>>>>> But I didn't want to go either way without consultation. I don't >>>>>> think this issue afflicts any chapter beyond the Menu Bar ch. >>>>>> >>>>>> >>>>>> Matt >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------- >>>>>> ----- >>>>>> *From:* Discuss >>>>>> > on behalf of Mick >>>>>> Chesterman >> > >>>>>> *Sent:* Monday, January 22, 2018 1:00 AM >>>>>> *To:* discuss at lists.flossmanuals.net >>>>>> >>>>>> *Subject:* Re: [FM Discuss] next steps on Audacity book >>>>>> >>>>>> >>>>>> HI there, >>>>>> >>>>>> >>>>>> >>>>>> This sounds good. Can anyone step forward to have a look over the >>>>>> Audacity manual before we do a pdf and epub print for the front page? >>>>>> >>>>>> I can do it at the weekend if not. >>>>>> >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> Mick >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Mick Chesterman >>>>>> >>>>>> Educational Innovation and Enterprise Tutor & >>>>>> >>>>>> EdLab Project Developer >>>>>> >>>>>> Department of Childhood, Youth and Education Studies. >>>>>> >>>>>> Manchester Metropolitan University >>>>>> >>>>>> Web: http://edlab.org.uk / Twitter: >>>>>> @EdLabMMU >>>>>> >>>>>> EdLab MMU - Exploring Educational Innovation and ... >>>>> >>>>>> edlab.org.uk > >>>>>> Exploring Educational Innovation and Enterprise in Education - >>>>>> Creatively generating projects rooted in community engagement and >>>>>> student experience. >>>>>> >>>>>> >>>>>> Phone: 0161 2472060 >>>>>> >>>>>> >>>>>> >>>>>> /Please note: My working days are Monday, Tuesday, Wednesday and >>>>> Thursday/ >>>>>> >>>>>> >>>>>> >>>>>> *From:*Discuss [mailto:discuss-bounces at lists.flossmanuals.net] *On >>>>>> Behalf Of *M R >>>>>> *Sent:* 18 January 2018 21:05 >>>>>> *To:* discuss at lists.flossmanuals.net >>>>>> >>>>>> *Subject:* Re: [FM Discuss] next steps on Audacity book >>>>>> >>>>>> >>>>>> >>>>>> Mick: >>>>>> >>>>>> >>>>>> >>>>>> It looks to me like other folks have finished adding in their >>>>>> pieces to the non-Windows sections of the manual re-write, so >>>>>> whenever you get a chance at some quality control (just because I >>>>>> assume that someone needs to, who hasn't been a >>>>>> writer-contributor), then we can wrap this up and get it published, >>>>>> to start helping whoever out there might actually want to use it. >>>>>> >>>>>> >>>>>> >>>>>> Actually, I suppose someone else could handle the review too -- not >>>>>> sure what the protocol is here. But I just wanted to make sure >>>>>> this stays in the queue as a near-term task. I assume we all have >>>>>> day jobs ?(I'm a college professor so I was just on holiday break >>>>>> -- that's why I could find 50 hrs or so to do the bulk of the rewrite). >>>>>> >>>>>> >>>>>> >>>>>> thanks, >>>>>> >>>>>> >>>>>> >>>>>> Matt >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------- >>>>>> ----- >>>>>> >>>>>> *From:*Discuss >>>>>> >>>>>> > on behalf of Mick >>>>>> Chesterman >> >>>>> > >>>>>> *Sent:* Friday, January 12, 2018 4:12 AM >>>>>> *To:* discuss at lists.flossmanuals.net >>>>>> >>>>> >>>>>> *Subject:* Re: [FM Discuss] next steps on Audacity book >>>>>> >>>>>> >>>>>> >>>>>> To exit chapter titles you just double click into the title on the >>>>>> chapter list screen. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:*Discuss >>>>>> >>>>>> > on behalf of M R >>>>>> >>>>>> > >>>>>> >>>>>> *Sent:*12 January 2018 10:55 >>>>>> *To:* discuss at lists.flossmanuals.net >>>>>> >>>>> >>>>>> *Subject:* Re: [FM Discuss] next steps on Audacity book >>>>>> >>>>>> >>>>>> >>>>>> I actually wanted to edit some of the other chapter TITLES a bit, >>>>>> but couldn't figure out a way to do that. No big deal though, as >>>>>> the current titles will serve. I did drag one entire chapter out >>>>>> of the to-be-published structure and down to the bottom: that was >>>>>> "MP3 INSTALLATION ON WINDOWS" bc it's no longer necessary to >>>>>> install the >>>>> LAME >>>>>> MP3 codec separately. Just one of many ways that Audacity has >>>>>> gotten more user-friendly over the years. >>>>>> >>>>>> >>>>>> >>>>>> "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 " >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Discuss mailing list >>>>>> Discuss at lists.flossmanuals.net >>>>>> >>>>>> http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net >>>>>> - you can >>>>> unsubscribe here >>>>>> >>>>> >>>> >>>> "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 " >>>> _______________________________________________ >>>> Discuss mailing list >>>> Discuss at lists.flossmanuals.net >>>> >>>> http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - >>>> you can unsubscribe here >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Discuss mailing list >>> Discuss at lists.flossmanuals.net >>> http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - >>> you can unsubscribe here >>> >> > > "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 " > _______________________________________________ > Discuss mailing list > Discuss at lists.flossmanuals.net > http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here > _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Check out Sea Serpent Design's cards and gifts? ... at Zazzle: [New Year Clock Card] New Year Clock Card ... at Redbubble: [Buy my art] _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Check out Sea Serpent Design's cards and gifts? ... at Zazzle: [Ladybug Hearts Card] Ladybug Hearts Card by rclord [Dog King and Queen of Hearts] Dog King and Queen of Hearts by rclord ... at Redbubble: [Buy my art] -------------- next part -------------- An HTML attachment was scrubbed... URL: From mick at flossmanuals.net Sun Feb 4 02:40:18 2018 From: mick at flossmanuals.net (mick at flossmanuals.net) Date: Sun, 4 Feb 2018 10:40:18 +0000 Subject: [FM Discuss] updated section on recording configuration using Audacity in Mac OS X In-Reply-To: References: <30e660dc-8d6f-4492-3516-c937e892db20@goos-habermann.de> <05554b58f2e347d693e00972ebdaf56b@BFEX02.ad.mmu.ac.uk> <0D3D2E08-94C6-4E53-91B9-52977C967F7D@seaserpent.com> <8d26e9a5-6492-46e5-f9d5-b4d0cbbf894e@goos-habermann.de> <9048b70d-97e9-17ce-e713-1f8984c69e26@goos-habermann.de> <6b389df7-c5fb-4f7a-ab0b-8f81c9b9a720@flossmanuals.net> Message-ID: <6fcc3002-d15d-dba3-5158-b39cc7aa123c@flossmanuals.net> Great, So the changes are is published to flossmanuals.net The relevant steps to do it are here. https://gitlab.com/flossmanuals/fm_en_splash/activity I have done a custom pdf generation using the default settings on the server. I'm pretty sure this can look a lot better but I don't have capacity to work on this so hoping that others in the community can work together on this one. Thanks On 03/02/18 04:27, M R wrote: > > thanks a lot, Rosalind -- I suspected that was the case. > > > So Mick, I think we might be clear to publish now, whenever you want > to pull the trigger. > > > best, > > > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matrobnew at hotmail.com Sun Feb 4 14:16:53 2018 From: matrobnew at hotmail.com (M R) Date: Sun, 4 Feb 2018 22:16:53 +0000 Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images In-Reply-To: <6fcc3002-d15d-dba3-5158-b39cc7aa123c@flossmanuals.net> References: <30e660dc-8d6f-4492-3516-c937e892db20@goos-habermann.de> <05554b58f2e347d693e00972ebdaf56b@BFEX02.ad.mmu.ac.uk> <0D3D2E08-94C6-4E53-91B9-52977C967F7D@seaserpent.com> <8d26e9a5-6492-46e5-f9d5-b4d0cbbf894e@goos-habermann.de> <9048b70d-97e9-17ce-e713-1f8984c69e26@goos-habermann.de> <6b389df7-c5fb-4f7a-ab0b-8f81c9b9a720@flossmanuals.net> , <6fcc3002-d15d-dba3-5158-b39cc7aa123c@flossmanuals.net> Message-ID: thanks Mick. I can now see the published 2.x version at flossmanuals.net. Perfectionist that I am, I did go in and make a few more wording changes to the Edit chapter (where it was entirely my own prose). I have not re-published; I figure I'd let others tinker with their own contributed areas for a while longer and we can re-publish wherever. Btw, I had been considering knocking out a new manual on ShutCut, an open-source video editor I've been using recently. So I was exploring existing Floss books on video editing to determine if there was a real need. The one manual I found that really focuses on a single video-editing tool uses Kdenlive, which is certainly a viable open-source alternative to ShotCut. However, in looking thu the published Kdenlive manual, I notice that every image link seems to be broken! Seriously, every single screenshot or other image. When you go into edit mode, the images don't appear at all; but in published mode they display as missing images. What might have caused this? Did some process nuke or move the entire image library? (it appears to be totally empty). I haven't found this issue with any other manuals I've reviewed yet, but I certainly haven't reviewed them all and am not really undertaking to at the moment. Nor do I really have time to spin up on Kdenlive such that I could replace all the missing images (even assuming I could figure out how to well enough from context). If I was going to put that kind of effort in, I'd do it with Shotcut. But I thought maybe you'd be aware of some simple behind-the-scenes operation that would restore all of the Kdenlive image files to their correct location. Matt ________________________________ From: Discuss on behalf of mick at flossmanuals.net Sent: Sunday, February 4, 2018 3:40 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] updated section on recording configuration using Audacity in Mac OS X Great, So the changes are is published to flossmanuals.net The relevant steps to do it are here. https://gitlab.com/flossmanuals/fm_en_splash/activity [https://assets.gitlab-static.net/assets/gitlab_logo-7ae504fe4f68fdebb3c2034e36621930cd36ea87924c11ff65dbcb8ed50dca58.png] Activity ? flossmanuals / fm_en_splash gitlab.com FLOSS Manuals EN Splash A splash page for FLOSS Manuals to replace current defunct publisher I have done a custom pdf generation using the default settings on the server. I'm pretty sure this can look a lot better but I don't have capacity to work on this so hoping that others in the community can work together on this one. Thanks On 03/02/18 04:27, M R wrote: thanks a lot, Rosalind -- I suspected that was the case. So Mick, I think we might be clear to publish now, whenever you want to pull the trigger. best, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Kean at op.ac.nz Sun Feb 4 16:12:34 2018 From: Martin.Kean at op.ac.nz (Martin Kean) Date: Mon, 5 Feb 2018 00:12:34 +0000 Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images In-Reply-To: References: <30e660dc-8d6f-4492-3516-c937e892db20@goos-habermann.de> <05554b58f2e347d693e00972ebdaf56b@BFEX02.ad.mmu.ac.uk> <0D3D2E08-94C6-4E53-91B9-52977C967F7D@seaserpent.com> <8d26e9a5-6492-46e5-f9d5-b4d0cbbf894e@goos-habermann.de> <9048b70d-97e9-17ce-e713-1f8984c69e26@goos-habermann.de> <6b389df7-c5fb-4f7a-ab0b-8f81c9b9a720@flossmanuals.net> , <6fcc3002-d15d-dba3-5158-b39cc7aa123c@flossmanuals.net>, Message-ID: Awesome! Looks great! What great teamwork, this is a good community! Mick I seem to have lost the path to PDF generation via Objavi, can you remind me please? Thanks, Martin ________________________________ From: Discuss on behalf of M R Sent: Monday, 5 February 2018 11:16:53 a.m. To: discuss at lists.flossmanuals.net Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images thanks Mick. I can now see the published 2.x version at flossmanuals.net. Perfectionist that I am, I did go in and make a few more wording changes to the Edit chapter (where it was entirely my own prose). I have not re-published; I figure I'd let others tinker with their own contributed areas for a while longer and we can re-publish wherever. Btw, I had been considering knocking out a new manual on ShutCut, an open-source video editor I've been using recently. So I was exploring existing Floss books on video editing to determine if there was a real need. The one manual I found that really focuses on a single video-editing tool uses Kdenlive, which is certainly a viable open-source alternative to ShotCut. However, in looking thu the published Kdenlive manual, I notice that every image link seems to be broken! Seriously, every single screenshot or other image. When you go into edit mode, the images don't appear at all; but in published mode they display as missing images. What might have caused this? Did some process nuke or move the entire image library? (it appears to be totally empty). I haven't found this issue with any other manuals I've reviewed yet, but I certainly haven't reviewed them all and am not really undertaking to at the moment. Nor do I really have time to spin up on Kdenlive such that I could replace all the missing images (even assuming I could figure out how to well enough from context). If I was going to put that kind of effort in, I'd do it with Shotcut. But I thought maybe you'd be aware of some simple behind-the-scenes operation that would restore all of the Kdenlive image files to their correct location. Matt ________________________________ From: Discuss on behalf of mick at flossmanuals.net Sent: Sunday, February 4, 2018 3:40 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] updated section on recording configuration using Audacity in Mac OS X Great, So the changes are is published to flossmanuals.net The relevant steps to do it are here. https://gitlab.com/flossmanuals/fm_en_splash/activity [https://assets.gitlab-static.net/assets/gitlab_logo-7ae504fe4f68fdebb3c2034e36621930cd36ea87924c11ff65dbcb8ed50dca58.png] Activity ? flossmanuals / fm_en_splash gitlab.com FLOSS Manuals EN Splash A splash page for FLOSS Manuals to replace current defunct publisher I have done a custom pdf generation using the default settings on the server. I'm pretty sure this can look a lot better but I don't have capacity to work on this so hoping that others in the community can work together on this one. Thanks On 03/02/18 04:27, M R wrote: thanks a lot, Rosalind -- I suspected that was the case. So Mick, I think we might be clear to publish now, whenever you want to pull the trigger. best, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.Chesterman at mmu.ac.uk Mon Feb 5 00:07:33 2018 From: M.Chesterman at mmu.ac.uk (Mick Chesterman) Date: Mon, 5 Feb 2018 08:07:33 +0000 Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images In-Reply-To: References: <30e660dc-8d6f-4492-3516-c937e892db20@goos-habermann.de> <05554b58f2e347d693e00972ebdaf56b@BFEX02.ad.mmu.ac.uk> <0D3D2E08-94C6-4E53-91B9-52977C967F7D@seaserpent.com> <8d26e9a5-6492-46e5-f9d5-b4d0cbbf894e@goos-habermann.de> <9048b70d-97e9-17ce-e713-1f8984c69e26@goos-habermann.de> <6b389df7-c5fb-4f7a-ab0b-8f81c9b9a720@flossmanuals.net> , <6fcc3002-d15d-dba3-5158-b39cc7aa123c@flossmanuals.net>, Message-ID: <6ead13b2273b42a28e0d2594a85c1d01@BFEX02.ad.mmu.ac.uk> Hi there Martin, In the newer interface you go to edit the book and then hit the publish tab. Thnx! Mick From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of Martin Kean Sent: 05 February 2018 00:13 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images Awesome! Looks great! What great teamwork, this is a good community! Mick I seem to have lost the path to PDF generation via Objavi, can you remind me please? Thanks, Martin ________________________________ From: Discuss > on behalf of M R > Sent: Monday, 5 February 2018 11:16:53 a.m. To: discuss at lists.flossmanuals.net Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images thanks Mick. I can now see the published 2.x version at flossmanuals.net. Perfectionist that I am, I did go in and make a few more wording changes to the Edit chapter (where it was entirely my own prose). I have not re-published; I figure I'd let others tinker with their own contributed areas for a while longer and we can re-publish wherever. Btw, I had been considering knocking out a new manual on ShutCut, an open-source video editor I've been using recently. So I was exploring existing Floss books on video editing to determine if there was a real need. The one manual I found that really focuses on a single video-editing tool uses Kdenlive, which is certainly a viable open-source alternative to ShotCut. However, in looking thu the published Kdenlive manual, I notice that every image link seems to be broken! Seriously, every single screenshot or other image. When you go into edit mode, the images don't appear at all; but in published mode they display as missing images. What might have caused this? Did some process nuke or move the entire image library? (it appears to be totally empty). I haven't found this issue with any other manuals I've reviewed yet, but I certainly haven't reviewed them all and am not really undertaking to at the moment. Nor do I really have time to spin up on Kdenlive such that I could replace all the missing images (even assuming I could figure out how to well enough from context). If I was going to put that kind of effort in, I'd do it with Shotcut. But I thought maybe you'd be aware of some simple behind-the-scenes operation that would restore all of the Kdenlive image files to their correct location. Matt ________________________________ From: Discuss > on behalf of mick at flossmanuals.net > Sent: Sunday, February 4, 2018 3:40 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] updated section on recording configuration using Audacity in Mac OS X Great, So the changes are is published to flossmanuals.net The relevant steps to do it are here. https://gitlab.com/flossmanuals/fm_en_splash/activity [https://assets.gitlab-static.net/assets/gitlab_logo-7ae504fe4f68fdebb3c2034e36621930cd36ea87924c11ff65dbcb8ed50dca58.png] Activity * flossmanuals / fm_en_splash gitlab.com FLOSS Manuals EN Splash A splash page for FLOSS Manuals to replace current defunct publisher I have done a custom pdf generation using the default settings on the server. I'm pretty sure this can look a lot better but I don't have capacity to work on this so hoping that others in the community can work together on this one. Thanks On 03/02/18 04:27, M R wrote: thanks a lot, Rosalind -- I suspected that was the case. So Mick, I think we might be clear to publish now, whenever you want to pull the trigger. best, Matt "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.Chesterman at mmu.ac.uk Mon Feb 5 00:18:47 2018 From: M.Chesterman at mmu.ac.uk (Mick Chesterman) Date: Mon, 5 Feb 2018 08:18:47 +0000 Subject: [FM Discuss] issues with Kdenlive manual images Message-ID: Good spot there Matt, I was going to suggest Kdenlive manual perhaps as a model for an open shot manual. The images *are* missing in that manual. I guess they need to be uploaded from here. Which is good to know as a way of rescuing manuals that were incompletely imported in to the new system. http://archive.flossmanuals.net/_booki/how-to-use-video-editing-software/how-to-use-video-editing-software.epub I've tested this and if it's done from the images and files section it is doable. I've done 10 or so but there are a lot so if anyone wants to chip in just go for it and post back you progress here. The process would be * Grab epub from above, * rename .zip, unzip it * go to http://write.flossmanuals.net/kdenlive/_edit/ * go to images and files tab * upload image from the static directory (one by one!) to this book * F5 - refresh to see the images appear. Thanks all! Mick From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of M R Sent: 04 February 2018 22:17 To: discuss at lists.flossmanuals.net Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images thanks Mick. I can now see the published 2.x version at flossmanuals.net. Perfectionist that I am, I did go in and make a few more wording changes to the Edit chapter (where it was entirely my own prose). I have not re-published; I figure I'd let others tinker with their own contributed areas for a while longer and we can re-publish wherever. Btw, I had been considering knocking out a new manual on ShutCut, an open-source video editor I've been using recently. So I was exploring existing Floss books on video editing to determine if there was a real need. The one manual I found that really focuses on a single video-editing tool uses Kdenlive, which is certainly a viable open-source alternative to ShotCut. However, in looking thu the published Kdenlive manual, I notice that every image link seems to be broken! Seriously, every single screenshot or other image. When you go into edit mode, the images don't appear at all; but in published mode they display as missing images. What might have caused this? Did some process nuke or move the entire image library? (it appears to be totally empty). I haven't found this issue with any other manuals I've reviewed yet, but I certainly haven't reviewed them all and am not really undertaking to at the moment. Nor do I really have time to spin up on Kdenlive such that I could replace all the missing images (even assuming I could figure out how to well enough from context). If I was going to put that kind of effort in, I'd do it with Shotcut. But I thought maybe you'd be aware of some simple behind-the-scenes operation that would restore all of the Kdenlive image files to their correct location. Matt ________________________________ From: Discuss > on behalf of mick at flossmanuals.net > Sent: Sunday, February 4, 2018 3:40 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] updated section on recording configuration using Audacity in Mac OS X Great, So the changes are is published to flossmanuals.net The relevant steps to do it are here. https://gitlab.com/flossmanuals/fm_en_splash/activity [https://assets.gitlab-static.net/assets/gitlab_logo-7ae504fe4f68fdebb3c2034e36621930cd36ea87924c11ff65dbcb8ed50dca58.png] Activity * flossmanuals / fm_en_splash gitlab.com FLOSS Manuals EN Splash A splash page for FLOSS Manuals to replace current defunct publisher I have done a custom pdf generation using the default settings on the server. I'm pretty sure this can look a lot better but I don't have capacity to work on this so hoping that others in the community can work together on this one. Thanks On 03/02/18 04:27, M R wrote: thanks a lot, Rosalind -- I suspected that was the case. So Mick, I think we might be clear to publish now, whenever you want to pull the trigger. best, Matt "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: From matrobnew at hotmail.com Mon Feb 5 01:59:08 2018 From: matrobnew at hotmail.com (M R) Date: Mon, 5 Feb 2018 09:59:08 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: Message-ID: Ok, so it sounds like from Mick that there IS a way to retrieve the missing Kdenlive images, but it's labor-intensive -- not as labor-intensive as capturing all new screen caps for every process, but then that raises the question of whether the original Kdenlive images (along with other info) are dated in the same way as for the 1.x Audacity manual, and thus would need to be replaced anyway. i think someone who actually uses and champions Kdenlive would need to take the lead on that. Left to my own devices I would probably adapt their basic structure to a ShotCut manual. matt ________________________________ From: Discuss on behalf of Mick Chesterman Sent: Monday, February 5, 2018 1:18 AM To: discuss at lists.flossmanuals.net Subject: [FM Discuss] issues with Kdenlive manual images Good spot there Matt, I was going to suggest Kdenlive manual perhaps as a model for an open shot manual. The images *are* missing in that manual. I guess they need to be uploaded from here. Which is good to know as a way of rescuing manuals that were incompletely imported in to the new system. http://archive.flossmanuals.net/_booki/how-to-use-video-editing-software/how-to-use-video-editing-software.epub I?ve tested this and if it?s done from the images and files section it is doable. I?ve done 10 or so but there are a lot so if anyone wants to chip in just go for it and post back you progress here. The process would be ? Grab epub from above, ? rename .zip, unzip it ? go to http://write.flossmanuals.net/kdenlive/_edit/ Booktype Sign In write.flossmanuals.net Free Manuals for Freedom ? go to images and files tab ? upload image from the static directory (one by one!) to this book ? F5 ? refresh to see the images appear. Thanks all! Mick From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of M R Sent: 04 February 2018 22:17 To: discuss at lists.flossmanuals.net Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images thanks Mick. I can now see the published 2.x version at flossmanuals.net. Perfectionist that I am, I did go in and make a few more wording changes to the Edit chapter (where it was entirely my own prose). I have not re-published; I figure I'd let others tinker with their own contributed areas for a while longer and we can re-publish wherever. Btw, I had been considering knocking out a new manual on ShutCut, an open-source video editor I've been using recently. So I was exploring existing Floss books on video editing to determine if there was a real need. The one manual I found that really focuses on a single video-editing tool uses Kdenlive, which is certainly a viable open-source alternative to ShotCut. However, in looking thu the published Kdenlive manual, I notice that every image link seems to be broken! Seriously, every single screenshot or other image. When you go into edit mode, the images don't appear at all; but in published mode they display as missing images. What might have caused this? Did some process nuke or move the entire image library? (it appears to be totally empty). I haven't found this issue with any other manuals I've reviewed yet, but I certainly haven't reviewed them all and am not really undertaking to at the moment. Nor do I really have time to spin up on Kdenlive such that I could replace all the missing images (even assuming I could figure out how to well enough from context). If I was going to put that kind of effort in, I'd do it with Shotcut. But I thought maybe you'd be aware of some simple behind-the-scenes operation that would restore all of the Kdenlive image files to their correct location. Matt ________________________________ From: Discuss > on behalf of mick at flossmanuals.net > Sent: Sunday, February 4, 2018 3:40 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] updated section on recording configuration using Audacity in Mac OS X Great, So the changes are is published to flossmanuals.net The relevant steps to do it are here. https://gitlab.com/flossmanuals/fm_en_splash/activity [https://assets.gitlab-static.net/assets/gitlab_logo-7ae504fe4f68fdebb3c2034e36621930cd36ea87924c11ff65dbcb8ed50dca58.png] Activity ? flossmanuals / fm_en_splash gitlab.com FLOSS Manuals EN Splash A splash page for FLOSS Manuals to replace current defunct publisher I have done a custom pdf generation using the default settings on the server. I'm pretty sure this can look a lot better but I don't have capacity to work on this so hoping that others in the community can work together on this one. Thanks On 03/02/18 04:27, M R wrote: thanks a lot, Rosalind -- I suspected that was the case. So Mick, I think we might be clear to publish now, whenever you want to pull the trigger. best, Matt "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Kean at op.ac.nz Mon Feb 5 16:39:21 2018 From: Martin.Kean at op.ac.nz (Martin Kean) Date: Tue, 6 Feb 2018 00:39:21 +0000 Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images In-Reply-To: <6ead13b2273b42a28e0d2594a85c1d01@BFEX02.ad.mmu.ac.uk> References: <30e660dc-8d6f-4492-3516-c937e892db20@goos-habermann.de> <05554b58f2e347d693e00972ebdaf56b@BFEX02.ad.mmu.ac.uk> <0D3D2E08-94C6-4E53-91B9-52977C967F7D@seaserpent.com> <8d26e9a5-6492-46e5-f9d5-b4d0cbbf894e@goos-habermann.de> <9048b70d-97e9-17ce-e713-1f8984c69e26@goos-habermann.de> <6b389df7-c5fb-4f7a-ab0b-8f81c9b9a720@flossmanuals.net> , <6fcc3002-d15d-dba3-5158-b39cc7aa123c@flossmanuals.net>, , <6ead13b2273b42a28e0d2594a85c1d01@BFEX02.ad.mmu.ac.uk> Message-ID: Thanks, I was looking for a similar button at flossmanuals.net I would like to open up a discussion about fonts, there seem to be only six to choose from: [cid:553bc96a-33e0-4249-8941-3e0baf4f112a] So for example what about Open Sans? It is a clear and clean typeface, great for technical texts. It is available under a Apache License v2.00. I welcome feedback : ) ________________________________ From: Discuss on behalf of Mick Chesterman Sent: Monday, 5 February 2018 9:07:33 p.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images Hi there Martin, In the newer interface you go to edit the book and then hit the publish tab. Thnx! Mick From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of Martin Kean Sent: 05 February 2018 00:13 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images Awesome! Looks great! What great teamwork, this is a good community! Mick I seem to have lost the path to PDF generation via Objavi, can you remind me please? Thanks, Martin ________________________________ From: Discuss > on behalf of M R > Sent: Monday, 5 February 2018 11:16:53 a.m. To: discuss at lists.flossmanuals.net Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images thanks Mick. I can now see the published 2.x version at flossmanuals.net. Perfectionist that I am, I did go in and make a few more wording changes to the Edit chapter (where it was entirely my own prose). I have not re-published; I figure I'd let others tinker with their own contributed areas for a while longer and we can re-publish wherever. Btw, I had been considering knocking out a new manual on ShutCut, an open-source video editor I've been using recently. So I was exploring existing Floss books on video editing to determine if there was a real need. The one manual I found that really focuses on a single video-editing tool uses Kdenlive, which is certainly a viable open-source alternative to ShotCut. However, in looking thu the published Kdenlive manual, I notice that every image link seems to be broken! Seriously, every single screenshot or other image. When you go into edit mode, the images don't appear at all; but in published mode they display as missing images. What might have caused this? Did some process nuke or move the entire image library? (it appears to be totally empty). I haven't found this issue with any other manuals I've reviewed yet, but I certainly haven't reviewed them all and am not really undertaking to at the moment. Nor do I really have time to spin up on Kdenlive such that I could replace all the missing images (even assuming I could figure out how to well enough from context). If I was going to put that kind of effort in, I'd do it with Shotcut. But I thought maybe you'd be aware of some simple behind-the-scenes operation that would restore all of the Kdenlive image files to their correct location. Matt ________________________________ From: Discuss > on behalf of mick at flossmanuals.net > Sent: Sunday, February 4, 2018 3:40 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] updated section on recording configuration using Audacity in Mac OS X Great, So the changes are is published to flossmanuals.net The relevant steps to do it are here. https://gitlab.com/flossmanuals/fm_en_splash/activity [https://assets.gitlab-static.net/assets/gitlab_logo-7ae504fe4f68fdebb3c2034e36621930cd36ea87924c11ff65dbcb8ed50dca58.png] Activity ? flossmanuals / fm_en_splash gitlab.com FLOSS Manuals EN Splash A splash page for FLOSS Manuals to replace current defunct publisher I have done a custom pdf generation using the default settings on the server. I'm pretty sure this can look a lot better but I don't have capacity to work on this so hoping that others in the community can work together on this one. Thanks On 03/02/18 04:27, M R wrote: thanks a lot, Rosalind -- I suspected that was the case. So Mick, I think we might be clear to publish now, whenever you want to pull the trigger. best, Matt "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2018-02-06 at 1.35.19 PM.png Type: image/png Size: 13160 bytes Desc: Screen Shot 2018-02-06 at 1.35.19 PM.png URL: From matrobnew at hotmail.com Mon Feb 5 17:04:59 2018 From: matrobnew at hotmail.com (M R) Date: Tue, 6 Feb 2018 01:04:59 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: Message-ID: Mick: Hey, let's suppose I was interested in launching a new manual for ShotCut, modeled to some extent on the Kdenlive, although probably from a somewhat different use-case angle than social activism just bc I haven't done a lot of activist video work. I actually researched and evaluated a number of open-source video editors, including Kdenlive, as well as numerous 'free' versions of non-free industrial software, and I decided personally that ShotCut was the way to go. The thing is, I don't seem to have the "Create New Book" button in my dashboard, where the Booktype manual suggests it should be (or anywhere else I can locate). Is this a role/permissions issue? I can create a new Group, and I can Import a book, but I don't find the Create New Book button in either the main dashboard tab or the My Books tab. What say you? Do you need to create the book for me, or give me additional permissions? thanks, Matt ________________________________ From: Discuss on behalf of Mick Chesterman Sent: Monday, February 5, 2018 1:18 AM To: discuss at lists.flossmanuals.net Subject: [FM Discuss] issues with Kdenlive manual images Good spot there Matt, I was going to suggest Kdenlive manual perhaps as a model for an open shot manual. The images *are* missing in that manual. I guess they need to be uploaded from here. Which is good to know as a way of rescuing manuals that were incompletely imported in to the new system. http://archive.flossmanuals.net/_booki/how-to-use-video-editing-software/how-to-use-video-editing-software.epub I?ve tested this and if it?s done from the images and files section it is doable. I?ve done 10 or so but there are a lot so if anyone wants to chip in just go for it and post back you progress here. The process would be ? Grab epub from above, ? rename .zip, unzip it ? go to http://write.flossmanuals.net/kdenlive/_edit/ Booktype Sign In write.flossmanuals.net Free Manuals for Freedom ? go to images and files tab ? upload image from the static directory (one by one!) to this book ? F5 ? refresh to see the images appear. Thanks all! Mick From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of M R Sent: 04 February 2018 22:17 To: discuss at lists.flossmanuals.net Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images thanks Mick. I can now see the published 2.x version at flossmanuals.net. Perfectionist that I am, I did go in and make a few more wording changes to the Edit chapter (where it was entirely my own prose). I have not re-published; I figure I'd let others tinker with their own contributed areas for a while longer and we can re-publish wherever. Btw, I had been considering knocking out a new manual on ShutCut, an open-source video editor I've been using recently. So I was exploring existing Floss books on video editing to determine if there was a real need. The one manual I found that really focuses on a single video-editing tool uses Kdenlive, which is certainly a viable open-source alternative to ShotCut. However, in looking thu the published Kdenlive manual, I notice that every image link seems to be broken! Seriously, every single screenshot or other image. When you go into edit mode, the images don't appear at all; but in published mode they display as missing images. What might have caused this? Did some process nuke or move the entire image library? (it appears to be totally empty). I haven't found this issue with any other manuals I've reviewed yet, but I certainly haven't reviewed them all and am not really undertaking to at the moment. Nor do I really have time to spin up on Kdenlive such that I could replace all the missing images (even assuming I could figure out how to well enough from context). If I was going to put that kind of effort in, I'd do it with Shotcut. But I thought maybe you'd be aware of some simple behind-the-scenes operation that would restore all of the Kdenlive image files to their correct location. Matt ________________________________ From: Discuss > on behalf of mick at flossmanuals.net > Sent: Sunday, February 4, 2018 3:40 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] updated section on recording configuration using Audacity in Mac OS X Great, So the changes are is published to flossmanuals.net The relevant steps to do it are here. https://gitlab.com/flossmanuals/fm_en_splash/activity [https://assets.gitlab-static.net/assets/gitlab_logo-7ae504fe4f68fdebb3c2034e36621930cd36ea87924c11ff65dbcb8ed50dca58.png] Activity ? flossmanuals / fm_en_splash gitlab.com FLOSS Manuals EN Splash A splash page for FLOSS Manuals to replace current defunct publisher I have done a custom pdf generation using the default settings on the server. I'm pretty sure this can look a lot better but I don't have capacity to work on this so hoping that others in the community can work together on this one. Thanks On 03/02/18 04:27, M R wrote: thanks a lot, Rosalind -- I suspected that was the case. So Mick, I think we might be clear to publish now, whenever you want to pull the trigger. best, Matt "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.Chesterman at mmu.ac.uk Mon Feb 5 23:56:16 2018 From: M.Chesterman at mmu.ac.uk (Mick Chesterman) Date: Tue, 6 Feb 2018 07:56:16 +0000 Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images In-Reply-To: References: <30e660dc-8d6f-4492-3516-c937e892db20@goos-habermann.de> <05554b58f2e347d693e00972ebdaf56b@BFEX02.ad.mmu.ac.uk> <0D3D2E08-94C6-4E53-91B9-52977C967F7D@seaserpent.com> <8d26e9a5-6492-46e5-f9d5-b4d0cbbf894e@goos-habermann.de> <9048b70d-97e9-17ce-e713-1f8984c69e26@goos-habermann.de> <6b389df7-c5fb-4f7a-ab0b-8f81c9b9a720@flossmanuals.net> , <6fcc3002-d15d-dba3-5158-b39cc7aa123c@flossmanuals.net>, , <6ead13b2273b42a28e0d2594a85c1d01@BFEX02.ad.mmu.ac.uk> Message-ID: <8ece9924ca764168aa886201ffaec070@BFEX02.ad.mmu.ac.uk> Hi there, Not tried this but here Adam suggested fontface in css. https://forum.sourcefabric.org/discussion/14805/questions-about-booktype-pro/p1 Thanks Mick From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of Martin Kean Sent: 06 February 2018 00:39 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images Thanks, I was looking for a similar button at flossmanuals.net I would like to open up a discussion about fonts, there seem to be only six to choose from: [cid:image001.png at 01D39F1F.F6377AF0] So for example what about Open Sans? It is a clear and clean typeface, great for technical texts. It is available under a Apache License v2.00. I welcome feedback : ) ________________________________ From: Discuss > on behalf of Mick Chesterman > Sent: Monday, 5 February 2018 9:07:33 p.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images Hi there Martin, In the newer interface you go to edit the book and then hit the publish tab. Thnx! Mick From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of Martin Kean Sent: 05 February 2018 00:13 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images Awesome! Looks great! What great teamwork, this is a good community! Mick I seem to have lost the path to PDF generation via Objavi, can you remind me please? Thanks, Martin ________________________________ From: Discuss > on behalf of M R > Sent: Monday, 5 February 2018 11:16:53 a.m. To: discuss at lists.flossmanuals.net Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images thanks Mick. I can now see the published 2.x version at flossmanuals.net. Perfectionist that I am, I did go in and make a few more wording changes to the Edit chapter (where it was entirely my own prose). I have not re-published; I figure I'd let others tinker with their own contributed areas for a while longer and we can re-publish wherever. Btw, I had been considering knocking out a new manual on ShutCut, an open-source video editor I've been using recently. So I was exploring existing Floss books on video editing to determine if there was a real need. The one manual I found that really focuses on a single video-editing tool uses Kdenlive, which is certainly a viable open-source alternative to ShotCut. However, in looking thu the published Kdenlive manual, I notice that every image link seems to be broken! Seriously, every single screenshot or other image. When you go into edit mode, the images don't appear at all; but in published mode they display as missing images. What might have caused this? Did some process nuke or move the entire image library? (it appears to be totally empty). I haven't found this issue with any other manuals I've reviewed yet, but I certainly haven't reviewed them all and am not really undertaking to at the moment. Nor do I really have time to spin up on Kdenlive such that I could replace all the missing images (even assuming I could figure out how to well enough from context). If I was going to put that kind of effort in, I'd do it with Shotcut. But I thought maybe you'd be aware of some simple behind-the-scenes operation that would restore all of the Kdenlive image files to their correct location. Matt ________________________________ From: Discuss > on behalf of mick at flossmanuals.net > Sent: Sunday, February 4, 2018 3:40 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] updated section on recording configuration using Audacity in Mac OS X Great, So the changes are is published to flossmanuals.net The relevant steps to do it are here. https://gitlab.com/flossmanuals/fm_en_splash/activity [https://assets.gitlab-static.net/assets/gitlab_logo-7ae504fe4f68fdebb3c2034e36621930cd36ea87924c11ff65dbcb8ed50dca58.png] Activity * flossmanuals / fm_en_splash gitlab.com FLOSS Manuals EN Splash A splash page for FLOSS Manuals to replace current defunct publisher I have done a custom pdf generation using the default settings on the server. I'm pretty sure this can look a lot better but I don't have capacity to work on this so hoping that others in the community can work together on this one. Thanks On 03/02/18 04:27, M R wrote: thanks a lot, Rosalind -- I suspected that was the case. So Mick, I think we might be clear to publish now, whenever you want to pull the trigger. best, Matt "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 13160 bytes Desc: image001.png URL: From M.Chesterman at mmu.ac.uk Tue Feb 6 00:00:34 2018 From: M.Chesterman at mmu.ac.uk (Mick Chesterman) Date: Tue, 6 Feb 2018 08:00:34 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: Message-ID: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> Hi there Matt, We were hit by spam a while back so I locked down that permission. I've opened it up now but we should keep an eye on new books here - http://write.flossmanuals.net/list-books/ Sounds good about the focus shift. We were commissioned by v4c.org to do that book on Kdenlive hence the social justice focus. It was me and Anna Morris that wrote the book so feel free to ask us questions about the process. Thanks Mick From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of M R Sent: 06 February 2018 01:05 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Mick: Hey, let's suppose I was interested in launching a new manual for ShotCut, modeled to some extent on the Kdenlive, although probably from a somewhat different use-case angle than social activism just bc I haven't done a lot of activist video work. I actually researched and evaluated a number of open-source video editors, including Kdenlive, as well as numerous 'free' versions of non-free industrial software, and I decided personally that ShotCut was the way to go. The thing is, I don't seem to have the "Create New Book" button in my dashboard, where the Booktype manual suggests it should be (or anywhere else I can locate). Is this a role/permissions issue? I can create a new Group, and I can Import a book, but I don't find the Create New Book button in either the main dashboard tab or the My Books tab. What say you? Do you need to create the book for me, or give me additional permissions? thanks, Matt ________________________________ From: Discuss > on behalf of Mick Chesterman > Sent: Monday, February 5, 2018 1:18 AM To: discuss at lists.flossmanuals.net Subject: [FM Discuss] issues with Kdenlive manual images Good spot there Matt, I was going to suggest Kdenlive manual perhaps as a model for an open shot manual. The images *are* missing in that manual. I guess they need to be uploaded from here. Which is good to know as a way of rescuing manuals that were incompletely imported in to the new system. http://archive.flossmanuals.net/_booki/how-to-use-video-editing-software/how-to-use-video-editing-software.epub I've tested this and if it's done from the images and files section it is doable. I've done 10 or so but there are a lot so if anyone wants to chip in just go for it and post back you progress here. The process would be * Grab epub from above, * rename .zip, unzip it * go to http://write.flossmanuals.net/kdenlive/_edit/ Booktype Sign In write.flossmanuals.net Free Manuals for Freedom * go to images and files tab * upload image from the static directory (one by one!) to this book * F5 - refresh to see the images appear. Thanks all! Mick From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of M R Sent: 04 February 2018 22:17 To: discuss at lists.flossmanuals.net Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images thanks Mick. I can now see the published 2.x version at flossmanuals.net. Perfectionist that I am, I did go in and make a few more wording changes to the Edit chapter (where it was entirely my own prose). I have not re-published; I figure I'd let others tinker with their own contributed areas for a while longer and we can re-publish wherever. Btw, I had been considering knocking out a new manual on ShutCut, an open-source video editor I've been using recently. So I was exploring existing Floss books on video editing to determine if there was a real need. The one manual I found that really focuses on a single video-editing tool uses Kdenlive, which is certainly a viable open-source alternative to ShotCut. However, in looking thu the published Kdenlive manual, I notice that every image link seems to be broken! Seriously, every single screenshot or other image. When you go into edit mode, the images don't appear at all; but in published mode they display as missing images. What might have caused this? Did some process nuke or move the entire image library? (it appears to be totally empty). I haven't found this issue with any other manuals I've reviewed yet, but I certainly haven't reviewed them all and am not really undertaking to at the moment. Nor do I really have time to spin up on Kdenlive such that I could replace all the missing images (even assuming I could figure out how to well enough from context). If I was going to put that kind of effort in, I'd do it with Shotcut. But I thought maybe you'd be aware of some simple behind-the-scenes operation that would restore all of the Kdenlive image files to their correct location. Matt ________________________________ From: Discuss > on behalf of mick at flossmanuals.net > Sent: Sunday, February 4, 2018 3:40 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] updated section on recording configuration using Audacity in Mac OS X Great, So the changes are is published to flossmanuals.net The relevant steps to do it are here. https://gitlab.com/flossmanuals/fm_en_splash/activity [https://assets.gitlab-static.net/assets/gitlab_logo-7ae504fe4f68fdebb3c2034e36621930cd36ea87924c11ff65dbcb8ed50dca58.png] Activity * flossmanuals / fm_en_splash gitlab.com FLOSS Manuals EN Splash A splash page for FLOSS Manuals to replace current defunct publisher I have done a custom pdf generation using the default settings on the server. I'm pretty sure this can look a lot better but I don't have capacity to work on this so hoping that others in the community can work together on this one. Thanks On 03/02/18 04:27, M R wrote: thanks a lot, Rosalind -- I suspected that was the case. So Mick, I think we might be clear to publish now, whenever you want to pull the trigger. best, Matt "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.Chesterman at mmu.ac.uk Tue Feb 6 00:09:36 2018 From: M.Chesterman at mmu.ac.uk (Mick Chesterman) Date: Tue, 6 Feb 2018 08:09:36 +0000 Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images In-Reply-To: <8ece9924ca764168aa886201ffaec070@BFEX02.ad.mmu.ac.uk> References: <30e660dc-8d6f-4492-3516-c937e892db20@goos-habermann.de> <05554b58f2e347d693e00972ebdaf56b@BFEX02.ad.mmu.ac.uk> <0D3D2E08-94C6-4E53-91B9-52977C967F7D@seaserpent.com> <8d26e9a5-6492-46e5-f9d5-b4d0cbbf894e@goos-habermann.de> <9048b70d-97e9-17ce-e713-1f8984c69e26@goos-habermann.de> <6b389df7-c5fb-4f7a-ab0b-8f81c9b9a720@flossmanuals.net> , <6fcc3002-d15d-dba3-5158-b39cc7aa123c@flossmanuals.net>, , <6ead13b2273b42a28e0d2594a85c1d01@BFEX02.ad.mmu.ac.uk> <8ece9924ca764168aa886201ffaec070@BFEX02.ad.mmu.ac.uk> Message-ID: <5adb066228cb412aab3e3850b569a314@BFEX02.ad.mmu.ac.uk> Also Martin, I just mined this useful post form the archives. https://web.archive.org/web/20120905100742/http://blog.booki.cc/2011/12/innovative-use-of-booki-css/ Mick From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of Mick Chesterman Sent: 06 February 2018 07:56 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images Hi there, Not tried this but here Adam suggested fontface in css. https://forum.sourcefabric.org/discussion/14805/questions-about-booktype-pro/p1 Thanks Mick From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of Martin Kean Sent: 06 February 2018 00:39 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images Thanks, I was looking for a similar button at flossmanuals.net I would like to open up a discussion about fonts, there seem to be only six to choose from: [cid:image001.png at 01D39F21.D2F67260] So for example what about Open Sans? It is a clear and clean typeface, great for technical texts. It is available under a Apache License v2.00. I welcome feedback : ) ________________________________ From: Discuss > on behalf of Mick Chesterman > Sent: Monday, 5 February 2018 9:07:33 p.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images Hi there Martin, In the newer interface you go to edit the book and then hit the publish tab. Thnx! Mick From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of Martin Kean Sent: 05 February 2018 00:13 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images Awesome! Looks great! What great teamwork, this is a good community! Mick I seem to have lost the path to PDF generation via Objavi, can you remind me please? Thanks, Martin ________________________________ From: Discuss > on behalf of M R > Sent: Monday, 5 February 2018 11:16:53 a.m. To: discuss at lists.flossmanuals.net Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images thanks Mick. I can now see the published 2.x version at flossmanuals.net. Perfectionist that I am, I did go in and make a few more wording changes to the Edit chapter (where it was entirely my own prose). I have not re-published; I figure I'd let others tinker with their own contributed areas for a while longer and we can re-publish wherever. Btw, I had been considering knocking out a new manual on ShutCut, an open-source video editor I've been using recently. So I was exploring existing Floss books on video editing to determine if there was a real need. The one manual I found that really focuses on a single video-editing tool uses Kdenlive, which is certainly a viable open-source alternative to ShotCut. However, in looking thu the published Kdenlive manual, I notice that every image link seems to be broken! Seriously, every single screenshot or other image. When you go into edit mode, the images don't appear at all; but in published mode they display as missing images. What might have caused this? Did some process nuke or move the entire image library? (it appears to be totally empty). I haven't found this issue with any other manuals I've reviewed yet, but I certainly haven't reviewed them all and am not really undertaking to at the moment. Nor do I really have time to spin up on Kdenlive such that I could replace all the missing images (even assuming I could figure out how to well enough from context). If I was going to put that kind of effort in, I'd do it with Shotcut. But I thought maybe you'd be aware of some simple behind-the-scenes operation that would restore all of the Kdenlive image files to their correct location. Matt ________________________________ From: Discuss > on behalf of mick at flossmanuals.net > Sent: Sunday, February 4, 2018 3:40 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] updated section on recording configuration using Audacity in Mac OS X Great, So the changes are is published to flossmanuals.net The relevant steps to do it are here. https://gitlab.com/flossmanuals/fm_en_splash/activity [https://assets.gitlab-static.net/assets/gitlab_logo-7ae504fe4f68fdebb3c2034e36621930cd36ea87924c11ff65dbcb8ed50dca58.png] Activity * flossmanuals / fm_en_splash gitlab.com FLOSS Manuals EN Splash A splash page for FLOSS Manuals to replace current defunct publisher I have done a custom pdf generation using the default settings on the server. I'm pretty sure this can look a lot better but I don't have capacity to work on this so hoping that others in the community can work together on this one. Thanks On 03/02/18 04:27, M R wrote: thanks a lot, Rosalind -- I suspected that was the case. So Mick, I think we might be clear to publish now, whenever you want to pull the trigger. best, Matt "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 13160 bytes Desc: image001.png URL: From matrobnew at hotmail.com Tue Feb 6 00:10:40 2018 From: matrobnew at hotmail.com (M R) Date: Tue, 6 Feb 2018 08:10:40 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> References: , <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> Message-ID: Mick: Cool -- I see the button now. No, I really liked the social justice focus in that Kden manual, and I liked all the general, tool-agnostic stuff about video editing. I just probably need to write out of my own experience, which has mostly been an intensive use of ShutCut for editing a particular video tutorial series that's now on youtube. In one sense, even doing a text-and-screenshot FM type how-to for ShotCut sort of goes against my better judgment. OTOH, there is sooo little extant ShotCut documention of any kind out there, so an FM manual could actually find some real use. Now I just have to find the time... Meanwhile, really a great experience working with the group on Audacity. It's a great group and a great platform. best, Matt ________________________________ From: Discuss on behalf of Mick Chesterman Sent: Tuesday, February 6, 2018 1:00 AM To: discuss at lists.flossmanuals.net Cc: Annafjmorris at gmail.com Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi there Matt, We were hit by spam a while back so I locked down that permission. I?ve opened it up now but we should keep an eye on new books here - http://write.flossmanuals.net/list-books/ Sounds good about the focus shift. We were commissioned by v4c.org to do that book on Kdenlive hence the social justice focus. It was me and Anna Morris that wrote the book so feel free to ask us questions about the process. Thanks Mick From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of M R Sent: 06 February 2018 01:05 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Mick: Hey, let's suppose I was interested in launching a new manual for ShotCut, modeled to some extent on the Kdenlive, although probably from a somewhat different use-case angle than social activism just bc I haven't done a lot of activist video work. I actually researched and evaluated a number of open-source video editors, including Kdenlive, as well as numerous 'free' versions of non-free industrial software, and I decided personally that ShotCut was the way to go. The thing is, I don't seem to have the "Create New Book" button in my dashboard, where the Booktype manual suggests it should be (or anywhere else I can locate). Is this a role/permissions issue? I can create a new Group, and I can Import a book, but I don't find the Create New Book button in either the main dashboard tab or the My Books tab. What say you? Do you need to create the book for me, or give me additional permissions? thanks, Matt ________________________________ From: Discuss > on behalf of Mick Chesterman > Sent: Monday, February 5, 2018 1:18 AM To: discuss at lists.flossmanuals.net Subject: [FM Discuss] issues with Kdenlive manual images Good spot there Matt, I was going to suggest Kdenlive manual perhaps as a model for an open shot manual. The images *are* missing in that manual. I guess they need to be uploaded from here. Which is good to know as a way of rescuing manuals that were incompletely imported in to the new system. http://archive.flossmanuals.net/_booki/how-to-use-video-editing-software/how-to-use-video-editing-software.epub I?ve tested this and if it?s done from the images and files section it is doable. I?ve done 10 or so but there are a lot so if anyone wants to chip in just go for it and post back you progress here. The process would be ? Grab epub from above, ? rename .zip, unzip it ? go to http://write.flossmanuals.net/kdenlive/_edit/ Booktype Sign In write.flossmanuals.net Free Manuals for Freedom ? go to images and files tab ? upload image from the static directory (one by one!) to this book ? F5 ? refresh to see the images appear. Thanks all! Mick From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of M R Sent: 04 February 2018 22:17 To: discuss at lists.flossmanuals.net Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images thanks Mick. I can now see the published 2.x version at flossmanuals.net. Perfectionist that I am, I did go in and make a few more wording changes to the Edit chapter (where it was entirely my own prose). I have not re-published; I figure I'd let others tinker with their own contributed areas for a while longer and we can re-publish wherever. Btw, I had been considering knocking out a new manual on ShutCut, an open-source video editor I've been using recently. So I was exploring existing Floss books on video editing to determine if there was a real need. The one manual I found that really focuses on a single video-editing tool uses Kdenlive, which is certainly a viable open-source alternative to ShotCut. However, in looking thu the published Kdenlive manual, I notice that every image link seems to be broken! Seriously, every single screenshot or other image. When you go into edit mode, the images don't appear at all; but in published mode they display as missing images. What might have caused this? Did some process nuke or move the entire image library? (it appears to be totally empty). I haven't found this issue with any other manuals I've reviewed yet, but I certainly haven't reviewed them all and am not really undertaking to at the moment. Nor do I really have time to spin up on Kdenlive such that I could replace all the missing images (even assuming I could figure out how to well enough from context). If I was going to put that kind of effort in, I'd do it with Shotcut. But I thought maybe you'd be aware of some simple behind-the-scenes operation that would restore all of the Kdenlive image files to their correct location. Matt ________________________________ From: Discuss > on behalf of mick at flossmanuals.net > Sent: Sunday, February 4, 2018 3:40 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] updated section on recording configuration using Audacity in Mac OS X Great, So the changes are is published to flossmanuals.net The relevant steps to do it are here. https://gitlab.com/flossmanuals/fm_en_splash/activity [https://assets.gitlab-static.net/assets/gitlab_logo-7ae504fe4f68fdebb3c2034e36621930cd36ea87924c11ff65dbcb8ed50dca58.png] Activity ? flossmanuals / fm_en_splash gitlab.com FLOSS Manuals EN Splash A splash page for FLOSS Manuals to replace current defunct publisher I have done a custom pdf generation using the default settings on the server. I'm pretty sure this can look a lot better but I don't have capacity to work on this so hoping that others in the community can work together on this one. Thanks On 03/02/18 04:27, M R wrote: thanks a lot, Rosalind -- I suspected that was the case. So Mick, I think we might be clear to publish now, whenever you want to pull the trigger. best, Matt "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: From matrobnew at hotmail.com Fri Feb 9 01:09:48 2018 From: matrobnew at hotmail.com (M R) Date: Fri, 9 Feb 2018 09:09:48 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: , <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk>, Message-ID: Mick: I've started work on the new Shotcut manual. The first few chapters were very light on images, but now I've gotten into screenshots, and I've encountered the same problem I did originally in the Audacity book: there seemed to be a max width of images that overrode any settings I might put in for an indiv image, and always results in a distorted screenshot image in the book unless the shot image itself is not very wide. I believe at one point with the Audacity book you mentioned that you'd increased the min image width to deal with this. Can you point me toward how to do this? By default, I'd like to work with a max screenshot size of 1366 by 768, though I can live with less width if I have to. But not as little as it's giving me now. thanks, matt ________________________________ From: Discuss on behalf of M R Sent: Tuesday, February 6, 2018 1:10 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Mick: Cool -- I see the button now. No, I really liked the social justice focus in that Kden manual, and I liked all the general, tool-agnostic stuff about video editing. I just probably need to write out of my own experience, which has mostly been an intensive use of ShutCut for editing a particular video tutorial series that's now on youtube. In one sense, even doing a text-and-screenshot FM type how-to for ShotCut sort of goes against my better judgment. OTOH, there is sooo little extant ShotCut documention of any kind out there, so an FM manual could actually find some real use. Now I just have to find the time... Meanwhile, really a great experience working with the group on Audacity. It's a great group and a great platform. best, Matt ________________________________ From: Discuss on behalf of Mick Chesterman Sent: Tuesday, February 6, 2018 1:00 AM To: discuss at lists.flossmanuals.net Cc: Annafjmorris at gmail.com Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi there Matt, We were hit by spam a while back so I locked down that permission. I?ve opened it up now but we should keep an eye on new books here - http://write.flossmanuals.net/list-books/ Sounds good about the focus shift. We were commissioned by v4c.org to do that book on Kdenlive hence the social justice focus. It was me and Anna Morris that wrote the book so feel free to ask us questions about the process. Thanks Mick From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of M R Sent: 06 February 2018 01:05 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Mick: Hey, let's suppose I was interested in launching a new manual for ShotCut, modeled to some extent on the Kdenlive, although probably from a somewhat different use-case angle than social activism just bc I haven't done a lot of activist video work. I actually researched and evaluated a number of open-source video editors, including Kdenlive, as well as numerous 'free' versions of non-free industrial software, and I decided personally that ShotCut was the way to go. The thing is, I don't seem to have the "Create New Book" button in my dashboard, where the Booktype manual suggests it should be (or anywhere else I can locate). Is this a role/permissions issue? I can create a new Group, and I can Import a book, but I don't find the Create New Book button in either the main dashboard tab or the My Books tab. What say you? Do you need to create the book for me, or give me additional permissions? thanks, Matt ________________________________ From: Discuss > on behalf of Mick Chesterman > Sent: Monday, February 5, 2018 1:18 AM To: discuss at lists.flossmanuals.net Subject: [FM Discuss] issues with Kdenlive manual images Good spot there Matt, I was going to suggest Kdenlive manual perhaps as a model for an open shot manual. The images *are* missing in that manual. I guess they need to be uploaded from here. Which is good to know as a way of rescuing manuals that were incompletely imported in to the new system. http://archive.flossmanuals.net/_booki/how-to-use-video-editing-software/how-to-use-video-editing-software.epub I?ve tested this and if it?s done from the images and files section it is doable. I?ve done 10 or so but there are a lot so if anyone wants to chip in just go for it and post back you progress here. The process would be ? Grab epub from above, ? rename .zip, unzip it ? go to http://write.flossmanuals.net/kdenlive/_edit/ Booktype Sign In write.flossmanuals.net Free Manuals for Freedom ? go to images and files tab ? upload image from the static directory (one by one!) to this book ? F5 ? refresh to see the images appear. Thanks all! Mick From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of M R Sent: 04 February 2018 22:17 To: discuss at lists.flossmanuals.net Subject: [FM Discuss] Yay on Audacity re-launch, and issues with Kdenlive manual images thanks Mick. I can now see the published 2.x version at flossmanuals.net. Perfectionist that I am, I did go in and make a few more wording changes to the Edit chapter (where it was entirely my own prose). I have not re-published; I figure I'd let others tinker with their own contributed areas for a while longer and we can re-publish wherever. Btw, I had been considering knocking out a new manual on ShutCut, an open-source video editor I've been using recently. So I was exploring existing Floss books on video editing to determine if there was a real need. The one manual I found that really focuses on a single video-editing tool uses Kdenlive, which is certainly a viable open-source alternative to ShotCut. However, in looking thu the published Kdenlive manual, I notice that every image link seems to be broken! Seriously, every single screenshot or other image. When you go into edit mode, the images don't appear at all; but in published mode they display as missing images. What might have caused this? Did some process nuke or move the entire image library? (it appears to be totally empty). I haven't found this issue with any other manuals I've reviewed yet, but I certainly haven't reviewed them all and am not really undertaking to at the moment. Nor do I really have time to spin up on Kdenlive such that I could replace all the missing images (even assuming I could figure out how to well enough from context). If I was going to put that kind of effort in, I'd do it with Shotcut. But I thought maybe you'd be aware of some simple behind-the-scenes operation that would restore all of the Kdenlive image files to their correct location. Matt ________________________________ From: Discuss > on behalf of mick at flossmanuals.net > Sent: Sunday, February 4, 2018 3:40 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] updated section on recording configuration using Audacity in Mac OS X Great, So the changes are is published to flossmanuals.net The relevant steps to do it are here. https://gitlab.com/flossmanuals/fm_en_splash/activity [https://assets.gitlab-static.net/assets/gitlab_logo-7ae504fe4f68fdebb3c2034e36621930cd36ea87924c11ff65dbcb8ed50dca58.png] Activity ? flossmanuals / fm_en_splash gitlab.com FLOSS Manuals EN Splash A splash page for FLOSS Manuals to replace current defunct publisher I have done a custom pdf generation using the default settings on the server. I'm pretty sure this can look a lot better but I don't have capacity to work on this so hoping that others in the community can work together on this one. Thanks On 03/02/18 04:27, M R wrote: thanks a lot, Rosalind -- I suspected that was the case. So Mick, I think we might be clear to publish now, whenever you want to pull the trigger. best, Matt "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: From mick at flossmanuals.net Fri Feb 9 01:23:00 2018 From: mick at flossmanuals.net (mick at flossmanuals.net) Date: Fri, 9 Feb 2018 09:23:00 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> Message-ID: Hi there, On 09/02/18 09:09, M R wrote: > By default, I'd like to work with a max screenshot size of 1366 by 768 This is good to discuss. We are limited by print output issues. I know the limit used to be 600px wide and I have always stuck to that. I'm ccing Daniel as I am pretty sure that this is a limit that has increased in Booktype 2.x and also he might have more knowledge of what happens if we use a wider images size in 1.6 and any potential hacks. Thanks Mick From maren at goos-habermann.de Fri Feb 9 04:48:16 2018 From: maren at goos-habermann.de (Maren Hachmann) Date: Fri, 9 Feb 2018 13:48:16 +0100 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> Message-ID: <6e2088a6-5a76-3dc5-43f5-3f2df40b46b5@goos-habermann.de> It's not going to be distorted (in the html version, if that's what you mean) if no size is given in the edit dialog for the images, and the 'keep aspect ratio' checkbox is checked. That's how Elisa did it in her book, and I've copied that for the Inkscape beginners' guide. Maren Am 09.02.2018 um 10:23 schrieb mick at flossmanuals.net: > Hi there, > > > On 09/02/18 09:09, M R wrote: >> By default, I'd like to work with a max screenshot size of 1366 by 768 > > This is good to discuss. We are limited by print output issues. > > I know the limit used to be 600px wide and I have always stuck to that. > > I'm ccing Daniel as I am pretty sure that this is a limit that has > increased in Booktype 2.x and also he might have more knowledge of what > happens if we use a wider images size in 1.6 and any potential hacks. > > Thanks > Mick > > _______________________________________________ > Discuss mailing list > Discuss at lists.flossmanuals.net > http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From annafjmorris at gmail.com Tue Feb 6 01:53:48 2018 From: annafjmorris at gmail.com (Anna F J Morris) Date: Tue, 6 Feb 2018 09:53:48 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> Message-ID: Hey Matt, sounds likea great project, don't hesitate to ask questions! Kind regards Anna On 6 Feb 2018 08:00, "Mick Chesterman" wrote: > Hi there Matt, > > > > We were hit by spam a while back so I locked down that permission. > > I?ve opened it up now but we should keep an eye on new books here - > http://write.flossmanuals.net/list-books/ > > > > Sounds good about the focus shift. We were commissioned by v4c.org to do > that book on Kdenlive hence the social justice focus. > > > > It was me and Anna Morris that wrote the book so feel free to ask us > questions about the process. > > > > Thanks > > Mick > > > > > > *From:* Discuss [mailto:discuss-bounces at lists.flossmanuals.net] *On > Behalf Of *M R > *Sent:* 06 February 2018 01:05 > *To:* discuss at lists.flossmanuals.net > *Subject:* Re: [FM Discuss] issues with Kdenlive manual images > > > > Mick: > > > > Hey, let's suppose I was interested in launching a new manual for > ShotCut, modeled to some extent on the Kdenlive, although probably from a > somewhat different use-case angle than social activism just bc I haven't > done a lot of activist video work. I actually researched and evaluated a > number of open-source video editors, including Kdenlive, as well as > numerous 'free' versions of non-free industrial software, and I decided > personally that ShotCut was the way to go. > > > > The thing is, I don't seem to have the "Create New Book" button in my > dashboard, where the Booktype manual suggests it should be (or anywhere > else I can locate). Is this a role/permissions issue? I can create a new > Group, and I can Import a book, but I don't find the Create New Book button > in either the main dashboard tab or the My Books tab. What say you? Do > you need to create the book for me, or give me additional permissions? > > > > thanks, > > > > Matt > > > ------------------------------ > > *From:* Discuss on behalf of > Mick Chesterman > *Sent:* Monday, February 5, 2018 1:18 AM > *To:* discuss at lists.flossmanuals.net > *Subject:* [FM Discuss] issues with Kdenlive manual images > > > > Good spot there Matt, > > > > I was going to suggest Kdenlive manual perhaps as a model for an open shot > manual. > > > > The images *are* missing in that manual. > > > > I guess they need to be uploaded from here. Which is good to know as a way > of rescuing manuals that were incompletely imported in to the new system. > > > * > http://archive.flossmanuals.net/_booki/how-to-use-video-editing-software/how-to-use-video-editing-software.epub > * > > > > I?ve tested this and if it?s done from the images and files section it is > doable. > > I?ve done 10 or so but there are a lot so if anyone wants to chip in just > go for it and post back you progress here. > > > > The process would be > > > > ? Grab epub from above, > > ? rename .zip, unzip it > > ? go to http://write.flossmanuals.net/kdenlive/_edit/ > > Booktype Sign In > > write.flossmanuals.net > > Free Manuals for Freedom > > > > ? go to images and files tab > > ? upload image from the static directory (one by one!) to this > book > > ? F5 ? refresh to see the images appear. > > > > Thanks all! > > Mick > > > > > > > > *From:* Discuss [mailto:discuss-bounces at lists.flossmanuals.net > ] *On Behalf Of *M R > *Sent:* 04 February 2018 22:17 > *To:* discuss at lists.flossmanuals.net > *Subject:* [FM Discuss] Yay on Audacity re-launch, and issues with > Kdenlive manual images > > > > thanks Mick. I can now see the published 2.x version at flossmanuals.net. > > > > Perfectionist that I am, I did go in and make a few more wording changes > to the Edit chapter (where it was entirely my own prose). I have not > re-published; I figure I'd let others tinker with their own contributed > areas for a while longer and we can re-publish wherever. > > > > Btw, I had been considering knocking out a new manual on ShutCut, an > open-source video editor I've been using recently. So I was exploring > existing Floss books on video editing to determine if there was a real > need. The one manual I found that really focuses on a single video-editing > tool uses Kdenlive, which is certainly a viable open-source alternative to > ShotCut. However, in looking thu the published Kdenlive manual, I notice > that every image link seems to be broken! Seriously, every single > screenshot or other image. When you go into edit mode, the images don't > appear at all; but in published mode they display as missing images. What > might have caused this? Did some process nuke or move the entire image > library? (it appears to be totally empty). I haven't found this issue with > any other manuals I've reviewed yet, but I certainly haven't reviewed them > all and am not really undertaking to at the moment. Nor do I really have > time to spin up on Kdenlive such that I could replace all the missing > images (even assuming I could figure out how to well enough from context). > If I was going to put that kind of effort in, I'd do it with Shotcut. > > > > But I thought maybe you'd be aware of some simple behind-the-scenes > operation that would restore all of the Kdenlive image files to their > correct location. > > > > Matt > > > ------------------------------ > > *From:* Discuss on behalf of > mick at flossmanuals.net > *Sent:* Sunday, February 4, 2018 3:40 AM > *To:* discuss at lists.flossmanuals.net > *Subject:* Re: [FM Discuss] updated section on recording configuration > using Audacity in Mac OS X > > > > Great, > > > > So the changes are is published to flossmanuals.net > > > > The relevant steps to do it are here. > > https://gitlab.com/flossmanuals/fm_en_splash/activity > > > > Activity ? flossmanuals / fm_en_splash > > > gitlab.com > > FLOSS Manuals EN Splash A splash page for FLOSS Manuals to replace current > defunct publisher > > > > > > I have done a custom pdf generation using the default settings on the > server. > I'm pretty sure this can look a lot better but I don't have capacity to > work on this so hoping that others in the community can work together on > this one. > > > > Thanks > > > > On 03/02/18 04:27, M R wrote: > > thanks a lot, Rosalind -- I suspected that was the case. > > > > So Mick, I think we might be clear to publish now, whenever you want to > pull the trigger. > > > > best, > > > > Matt > > > > > > "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 " > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.james at booktype.org Fri Feb 9 04:41:49 2018 From: daniel.james at booktype.org (Daniel James) Date: Fri, 9 Feb 2018 12:41:49 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> Message-ID: <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> Hi Mick, > I know the limit used to be 600px wide and I have always stuck to that. Booktype has come a long way since those days :-) > I am pretty sure that this is a limit that has > increased in Booktype 2.x and also he might have more knowledge of what > happens if we use a wider images size in 1.6 and any potential hacks. In Booktype 2.3 you can use any image size you want, as long as the resolution is high enough for print output (should that be one of your targets). There are also tools for zooming, cropping etc. built in. Cheers! Daniel From matrobnew at hotmail.com Fri Feb 9 12:16:03 2018 From: matrobnew at hotmail.com (M R) Date: Fri, 9 Feb 2018 20:16:03 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> , <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> Message-ID: Hi All: Thanks so much for the prompt replies to my questions. Although this does leave me a dilemma. If there really is a hard limit of 600 px width for images in Booktype 1.6 (and no prospect of migration soon to 2.3), then I guess I need to decide how much I care about the print format (or maybe PDF too?) as opposed to the html version. I've always felt that FM was most useful in it's html format, and then perhaps secondarily as an ePUB book export. So one follow-up question for Mick is whether the width restriction applies to ePUB format as well? I'm guessing it does, based on my ePUB version of the rewritten Audacity manual. Actually, now that I look at it closely, that ePUB suffers from many of the same formatting issues as the PDF--so I guess I won't go around showing that version to everybody ?. Meanwhile, though, Maren is correct: the restriction on image width (and resulting distortion) seems to disappear when you look at a published book in html format, or even "View Draft" of a book in progress from the main book page, e.g. http://write.flossmanuals.net/introduction-to-video-editing-with-shotcut/_info/ in the case of my new manual. This is interesting because the same 1366-width screenshot (see the Installing chapter) shows up distorted not just in the editor, but also when you hit "View Chapter" from within the editor, and expand that new window as much as possible. You have to "View Draft" from the main book page to see the image properly proportioned in that chapter. Btw, Maren's Inkscape book is absolutely gorgeous, but as far as I can tell most of the images there seem to actually stay within the 600 or 700 px limit. I did that myself with the Audacity book, in order to avoid what I thought was otherwise inescapable distortion. I have tons of screenshots but I sized my Audacity window itself as small as I felt I could, practically, and then generally just captured a particular panel or region or control area of it. I'll see to what extent that works for Shotcut too. 600 px is a pretty draconian limit for modern screenshots, though, as no one in their right might would use most of these editing tools at that width. I get that the print version needs some kind of image width limit. One would think that the "Constrain Proportions" function would at least, you know, constrain proportions if the image exceeded that limit, and simply show a smaller overall screenshot. But I can't get that to work in the editor: it seems to always take the actual height but constain the width. No doubt why they fixed it in 2.2... Matt ________________________________ From: Discuss on behalf of Daniel James Sent: Friday, February 9, 2018 5:41 AM To: mick at flossmanuals.net; discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Mick, > I know the limit used to be 600px wide and I have always stuck to that. Booktype has come a long way since those days :-) > I am pretty sure that this is a limit that has > increased in Booktype 2.x and also he might have more knowledge of what > happens if we use a wider images size in 1.6 and any potential hacks. In Booktype 2.3 you can use any image size you want, as long as the resolution is high enough for print output (should that be one of your targets). There are also tools for zooming, cropping etc. built in. Cheers! Daniel _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Discuss Info Page - lists.flossmanuals.net lists.flossmanuals.net 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 ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From matrobnew at hotmail.com Fri Feb 9 14:04:33 2018 From: matrobnew at hotmail.com (M R) Date: Fri, 9 Feb 2018 22:04:33 +0000 Subject: [FM Discuss] Mac and Linux users for Shotcut? In-Reply-To: References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> , <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org>, Message-ID: All: I should add that, as with the Audacity rewrite, for this new Shotcut manual I will need to ask the community if any Mac and Linux users are willing to give the install a try, to finish out the "Installation" chapter (at http://write.flossmanuals.net/introduction-to-video-editing-with-shotcut/_edit/ ). Shotcut is very lightweight, in good open-source fashion, and the Windows install was smooth and quick. It doesn't appear that there are any major gotchas for MacOS, and while the Linux install seems a bit more elaborate, to my Windows eyes, I'm sure it's SOP for Linux installs. Moreover, I really do think Shotcut is a fantastic video editor, amazingly light-footprint for what it does; so it might even be worth keeping around unless you're deeply committed to an alternative. After doing some research I picked it over Kden, among free open-source editors, before knowing that there a Floss Kden manual and far less Shotcut documentation around anywhere (which is why I'm writing this book). Indeed,I would absolutely be open to people suggesting their own 'how to' chapters as well, on whatever OS, though that will need to be a separate conversation as I haven't yet figured out which how-to's I intend to do myself ?, or will have time for. I can say that my video editing literacy is still pretty basic; for example I know nothing at all about topics like color treatment, or really about half of the "Video Effects" features they list here: https://shotcut.org/features/ The shotcut team are a couple of guys who've put their energy into building a really nice open-source editor, and not at all into explaining its features in any depth. To a great extent they are relying on users to have decent prior literacy in the field. I am hoping that someone out there has more than I do. Certainly the Kden writers, though you'd have to decide if you want to show the love for a competing editor... Thanks, Matt ________________________________ From: Discuss on behalf of M R Sent: Friday, February 9, 2018 1:16 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi All: Thanks so much for the prompt replies to my questions. Although this does leave me a dilemma. If there really is a hard limit of 600 px width for images in Booktype 1.6 (and no prospect of migration soon to 2.3), then I guess I need to decide how much I care about the print format (or maybe PDF too?) as opposed to the html version. I've always felt that FM was most useful in it's html format, and then perhaps secondarily as an ePUB book export. So one follow-up question for Mick is whether the width restriction applies to ePUB format as well? I'm guessing it does, based on my ePUB version of the rewritten Audacity manual. Actually, now that I look at it closely, that ePUB suffers from many of the same formatting issues as the PDF--so I guess I won't go around showing that version to everybody ?. Meanwhile, though, Maren is correct: the restriction on image width (and resulting distortion) seems to disappear when you look at a published book in html format, or even "View Draft" of a book in progress from the main book page, e.g. http://write.flossmanuals.net/introduction-to-video-editing-with-shotcut/_info/ in the case of my new manual. This is interesting because the same 1366-width screenshot (see the Installing chapter) shows up distorted not just in the editor, but also when you hit "View Chapter" from within the editor, and expand that new window as much as possible. You have to "View Draft" from the main book page to see the image properly proportioned in that chapter. Btw, Maren's Inkscape book is absolutely gorgeous, but as far as I can tell most of the images there seem to actually stay within the 600 or 700 px limit. I did that myself with the Audacity book, in order to avoid what I thought was otherwise inescapable distortion. I have tons of screenshots but I sized my Audacity window itself as small as I felt I could, practically, and then generally just captured a particular panel or region or control area of it. I'll see to what extent that works for Shotcut too. 600 px is a pretty draconian limit for modern screenshots, though, as no one in their right might would use most of these editing tools at that width. I get that the print version needs some kind of image width limit. One would think that the "Constrain Proportions" function would at least, you know, constrain proportions if the image exceeded that limit, and simply show a smaller overall screenshot. But I can't get that to work in the editor: it seems to always take the actual height but constain the width. No doubt why they fixed it in 2.2... Matt ________________________________ From: Discuss on behalf of Daniel James Sent: Friday, February 9, 2018 5:41 AM To: mick at flossmanuals.net; discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Mick, > I know the limit used to be 600px wide and I have always stuck to that. Booktype has come a long way since those days :-) > I am pretty sure that this is a limit that has > increased in Booktype 2.x and also he might have more knowledge of what > happens if we use a wider images size in 1.6 and any potential hacks. In Booktype 2.3 you can use any image size you want, as long as the resolution is high enough for print output (should that be one of your targets). There are also tools for zooming, cropping etc. built in. Cheers! Daniel _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Discuss Info Page - lists.flossmanuals.net lists.flossmanuals.net 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 ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From rclord at seaserpent.com Fri Feb 9 16:28:41 2018 From: rclord at seaserpent.com (Rosalind Lord) Date: Fri, 9 Feb 2018 16:28:41 -0800 Subject: [FM Discuss] Mac and Linux users for Shotcut? In-Reply-To: References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> Message-ID: <0B8E4150-EDB2-45D5-B869-D95333B51407@seaserpent.com> I?m a Mac user, so I can try installing Shotcut. I?ve done video editing before. - Rosalind > On Feb 9, 2018, at 2:04 PM, M R wrote: > > All: > > I should add that, as with the Audacity rewrite, for this new Shotcut manual I will need to ask the community if any Mac and Linux users are willing to give the install a try, to finish out the "Installation" chapter (at http://write.flossmanuals.net/introduction-to-video-editing-with-shotcut/_edit/ ). Shotcut is very lightweight, in good open-source fashion, and the Windows install was smooth and quick. It doesn't appear that there are any major gotchas for MacOS, and while the Linux install seems a bit more elaborate, to my Windows eyes, I'm sure it's SOP for Linux installs. Moreover, I really do think Shotcut is a fantastic video editor, amazingly light-footprint for what it does; so it might even be worth keeping around unless you're deeply committed to an alternative. After doing some research I picked it over Kden, among free open-source editors, before knowing that there a Floss Kden manual and far less Shotcut documentation around anywhere (which is why I'm writing this book). > > Indeed,I would absolutely be open to people suggesting their own 'how to' chapters as well, on whatever OS, though that will need to be a separate conversation as I haven't yet figured out which how-to's I intend to do myself ?, or will have time for. I can say that my video editing literacy is still pretty basic; for example I know nothing at all about topics like color treatment, or really about half of the "Video Effects" features they list here: https://shotcut.org/features/ The shotcut team are a couple of guys who've put their energy into building a really nice open-source editor, and not at all into explaining its features in any depth. To a great extent they are relying on users to have decent prior literacy in the field. I am hoping that someone out there has more than I do. Certainly the Kden writers, though you'd have to decide if you want to show the love for a competing editor... > > Thanks, > > Matt > > > > > From: Discuss > on behalf of M R > > Sent: Friday, February 9, 2018 1:16 PM > To: discuss at lists.flossmanuals.net > Subject: Re: [FM Discuss] issues with Kdenlive manual images > > Hi All: > > Thanks so much for the prompt replies to my questions. Although this does leave me a dilemma. If there really is a hard limit of 600 px width for images in Booktype 1.6 (and no prospect of migration soon to 2.3), then I guess I need to decide how much I care about the print format (or maybe PDF too?) as opposed to the html version. I've always felt that FM was most useful in it's html format, and then perhaps secondarily as an ePUB book export. So one follow-up question for Mick is whether the width restriction applies to ePUB format as well? I'm guessing it does, based on my ePUB version of the rewritten Audacity manual. Actually, now that I look at it closely, that ePUB suffers from many of the same formatting issues as the PDF--so I guess I won't go around showing that version to everybody ?. > > Meanwhile, though, Maren is correct: the restriction on image width (and resulting distortion) seems to disappear when you look at a published book in html format, or even "View Draft" of a book in progress from the main book page, e.g. http://write.flossmanuals.net/introduction-to-video-editing-with-shotcut/_info/ in the case of my new manual. This is interesting because the same 1366-width screenshot (see the Installing chapter) shows up distorted not just in the editor, but also when you hit "View Chapter" from within the editor, and expand that new window as much as possible. You have to "View Draft" from the main book page to see the image properly proportioned in that chapter. Btw, Maren's Inkscape book is absolutely gorgeous, but as far as I can tell most of the images there seem to actually stay within the 600 or 700 px limit. I did that myself with the Audacity book, in order to avoid what I thought was otherwise inescapable distortion. I have tons of screenshots but I sized my Audacity window itself as small as I felt I could, practically, and then generally just captured a particular panel or region or control area of it. I'll see to what extent that works for Shotcut too. 600 px is a pretty draconian limit for modern screenshots, though, as no one in their right might would use most of these editing tools at that width. I get that the print version needs some kind of image width limit. One would think that the "Constrain Proportions" function would at least, you know, constrain proportions if the image exceeded that limit, and simply show a smaller overall screenshot. But I can't get that to work in the editor: it seems to always take the actual height but constain the width. No doubt why they fixed it in 2.2... > > Matt > > > From: Discuss > on behalf of Daniel James > > Sent: Friday, February 9, 2018 5:41 AM > To: mick at flossmanuals.net ; discuss at lists.flossmanuals.net > Subject: Re: [FM Discuss] issues with Kdenlive manual images > > Hi Mick, > > > I know the limit used to be 600px wide and I have always stuck to that. > > Booktype has come a long way since those days :-) > > > I am pretty sure that this is a limit that has > > increased in Booktype 2.x and also he might have more knowledge of what > > happens if we use a wider images size in 1.6 and any potential hacks. > > In Booktype 2.3 you can use any image size you want, as long as the > resolution is high enough for print output (should that be one of your > targets). There are also tools for zooming, cropping etc. built in. > > Cheers! > > Daniel > _______________________________________________ > Discuss mailing list > Discuss at lists.flossmanuals.net > http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here > Discuss Info Page - lists.flossmanuals.net > lists.flossmanuals.net > 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 ... > > > _______________________________________________ > Discuss mailing list > Discuss at lists.flossmanuals.net > http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Check out Sea Serpent Design's cards and gifts ? ... at Zazzle: Ladybug Hearts Card by rclord Dog King and Queen of Hearts by rclord ... at Redbubble: -------------- next part -------------- An HTML attachment was scrubbed... URL: From matrobnew at hotmail.com Fri Feb 9 16:44:14 2018 From: matrobnew at hotmail.com (M R) Date: Sat, 10 Feb 2018 00:44:14 +0000 Subject: [FM Discuss] Mac and Linux users for Shotcut? In-Reply-To: <0B8E4150-EDB2-45D5-B869-D95333B51407@seaserpent.com> References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> , <0B8E4150-EDB2-45D5-B869-D95333B51407@seaserpent.com> Message-ID: That would be awesome, Rosalind. Any video editing knowledge is just a bonus, for this purpose (documenting the install process for Mac), but once you have it installed, I'd love to get your impression of the tool. Probably the best quick-start reference around is the chapter I'm working on right now ?--that's not about my documenting prowess but just the stark lack of documentation other than a handful of videos on very specific operations. Not sure if you can view my chapter while I have it open for edit, but I'll be off shortly. The install chapter is checked in so you can have at it. Matt ________________________________ From: Discuss on behalf of Rosalind Lord Sent: Friday, February 9, 2018 5:28 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] Mac and Linux users for Shotcut? I?m a Mac user, so I can try installing Shotcut. I?ve done video editing before. - Rosalind On Feb 9, 2018, at 2:04 PM, M R > wrote: All: I should add that, as with the Audacity rewrite, for this new Shotcut manual I will need to ask the community if any Mac and Linux users are willing to give the install a try, to finish out the "Installation" chapter (at http://write.flossmanuals.net/introduction-to-video-editing-with-shotcut/_edit/ ). Shotcut is very lightweight, in good open-source fashion, and the Windows install was smooth and quick. It doesn't appear that there are any major gotchas for MacOS, and while the Linux install seems a bit more elaborate, to my Windows eyes, I'm sure it's SOP for Linux installs. Moreover, I really do think Shotcut is a fantastic video editor, amazingly light-footprint for what it does; so it might even be worth keeping around unless you're deeply committed to an alternative. After doing some research I picked it over Kden, among free open-source editors, before knowing that there a Floss Kden manual and far less Shotcut documentation around anywhere (which is why I'm writing this book). Indeed,I would absolutely be open to people suggesting their own 'how to' chapters as well, on whatever OS, though that will need to be a separate conversation as I haven't yet figured out which how-to's I intend to do myself ?, or will have time for. I can say that my video editing literacy is still pretty basic; for example I know nothing at all about topics like color treatment, or really about half of the "Video Effects" features they list here: https://shotcut.org/features/ The shotcut team are a couple of guys who've put their energy into building a really nice open-source editor, and not at all into explaining its features in any depth. To a great extent they are relying on users to have decent prior literacy in the field. I am hoping that someone out there has more than I do. Certainly the Kden writers, though you'd have to decide if you want to show the love for a competing editor... Thanks, Matt ________________________________ From: Discuss > on behalf of M R > Sent: Friday, February 9, 2018 1:16 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi All: Thanks so much for the prompt replies to my questions. Although this does leave me a dilemma. If there really is a hard limit of 600 px width for images in Booktype 1.6 (and no prospect of migration soon to 2.3), then I guess I need to decide how much I care about the print format (or maybe PDF too?) as opposed to the html version. I've always felt that FM was most useful in it's html format, and then perhaps secondarily as an ePUB book export. So one follow-up question for Mick is whether the width restriction applies to ePUB format as well? I'm guessing it does, based on my ePUB version of the rewritten Audacity manual. Actually, now that I look at it closely, that ePUB suffers from many of the same formatting issues as the PDF--so I guess I won't go around showing that version to everybody ?. Meanwhile, though, Maren is correct: the restriction on image width (and resulting distortion) seems to disappear when you look at a published book in html format, or even "View Draft" of a book in progress from the main book page, e.g. http://write.flossmanuals.net/introduction-to-video-editing-with-shotcut/_info/ in the case of my new manual. This is interesting because the same 1366-width screenshot (see the Installing chapter) shows up distorted not just in the editor, but also when you hit "View Chapter" from within the editor, and expand that new window as much as possible. You have to "View Draft" from the main book page to see the image properly proportioned in that chapter. Btw, Maren's Inkscape book is absolutely gorgeous, but as far as I can tell most of the images there seem to actually stay within the 600 or 700 px limit. I did that myself with the Audacity book, in order to avoid what I thought was otherwise inescapable distortion. I have tons of screenshots but I sized my Audacity window itself as small as I felt I could, practically, and then generally just captured a particular panel or region or control area of it. I'll see to what extent that works for Shotcut too. 600 px is a pretty draconian limit for modern screenshots, though, as no one in their right might would use most of these editing tools at that width. I get that the print version needs some kind of image width limit. One would think that the "Constrain Proportions" function would at least, you know, constrain proportions if the image exceeded that limit, and simply show a smaller overall screenshot. But I can't get that to work in the editor: it seems to always take the actual height but constain the width. No doubt why they fixed it in 2.2... Matt ________________________________ From: Discuss > on behalf of Daniel James > Sent: Friday, February 9, 2018 5:41 AM To: mick at flossmanuals.net; discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Mick, > I know the limit used to be 600px wide and I have always stuck to that. Booktype has come a long way since those days :-) > I am pretty sure that this is a limit that has > increased in Booktype 2.x and also he might have more knowledge of what > happens if we use a wider images size in 1.6 and any potential hacks. In Booktype 2.3 you can use any image size you want, as long as the resolution is high enough for print output (should that be one of your targets). There are also tools for zooming, cropping etc. built in. Cheers! Daniel _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Discuss Info Page - lists.flossmanuals.net lists.flossmanuals.net 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 ... _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Check out Sea Serpent Design's cards and gifts? ... at Zazzle: [Ladybug Hearts Card] Ladybug Hearts Card by rclord [Dog King and Queen of Hearts] Dog King and Queen of Hearts by rclord ... at Redbubble: [Buy my art] -------------- next part -------------- An HTML attachment was scrubbed... URL: From rclord at seaserpent.com Fri Feb 9 16:53:13 2018 From: rclord at seaserpent.com (Rosalind Lord) Date: Fri, 9 Feb 2018 16:53:13 -0800 Subject: [FM Discuss] Mac and Linux users for Shotcut? In-Reply-To: References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> <0B8E4150-EDB2-45D5-B869-D95333B51407@seaserpent.com> Message-ID: <3857F0A9-317F-4773-9A93-41097B19AD4F@seaserpent.com> Awesome. I will get started. - Rosalind > On Feb 9, 2018, at 4:44 PM, M R wrote: > > That would be awesome, Rosalind. Any video editing knowledge is just a bonus, for this purpose (documenting the install process for Mac), but once you have it installed, I'd love to get your impression of the tool. Probably the best quick-start reference around is the chapter I'm working on right now ?--that's not about my documenting prowess but just the stark lack of documentation other than a handful of videos on very specific operations. Not sure if you can view my chapter while I have it open for edit, but I'll be off shortly. The install chapter is checked in so you can have at it. > > Matt > > > From: Discuss on behalf of Rosalind Lord > Sent: Friday, February 9, 2018 5:28 PM > To: discuss at lists.flossmanuals.net > Subject: Re: [FM Discuss] Mac and Linux users for Shotcut? > > I?m a Mac user, so I can try installing Shotcut. > > I?ve done video editing before. > > - Rosalind > >> On Feb 9, 2018, at 2:04 PM, M R > wrote: >> >> All: >> >> I should add that, as with the Audacity rewrite, for this new Shotcut manual I will need to ask the community if any Mac and Linux users are willing to give the install a try, to finish out the "Installation" chapter (at http://write.flossmanuals.net/introduction-to-video-editing-with-shotcut/_edit/ ). Shotcut is very lightweight, in good open-source fashion, and the Windows install was smooth and quick. It doesn't appear that there are any major gotchas for MacOS, and while the Linux install seems a bit more elaborate, to my Windows eyes, I'm sure it's SOP for Linux installs. Moreover, I really do think Shotcut is a fantastic video editor, amazingly light-footprint for what it does; so it might even be worth keeping around unless you're deeply committed to an alternative. After doing some research I picked it over Kden, among free open-source editors, before knowing that there a Floss Kden manual and far less Shotcut documentation around anywhere (which is why I'm writing this book). >> >> Indeed,I would absolutely be open to people suggesting their own 'how to' chapters as well, on whatever OS, though that will need to be a separate conversation as I haven't yet figured out which how-to's I intend to do myself ?, or will have time for. I can say that my video editing literacy is still pretty basic; for example I know nothing at all about topics like color treatment, or really about half of the "Video Effects" features they list here: https://shotcut.org/features/ The shotcut team are a couple of guys who've put their energy into building a really nice open-source editor, and not at all into explaining its features in any depth. To a great extent they are relying on users to have decent prior literacy in the field. I am hoping that someone out there has more than I do. Certainly the Kden writers, though you'd have to decide if you want to show the love for a competing editor... >> >> Thanks, >> >> Matt >> >> >> >> >> From: Discuss > on behalf of M R > >> Sent: Friday, February 9, 2018 1:16 PM >> To: discuss at lists.flossmanuals.net >> Subject: Re: [FM Discuss] issues with Kdenlive manual images >> >> Hi All: >> >> Thanks so much for the prompt replies to my questions. Although this does leave me a dilemma. If there really is a hard limit of 600 px width for images in Booktype 1.6 (and no prospect of migration soon to 2.3), then I guess I need to decide how much I care about the print format (or maybe PDF too?) as opposed to the html version. I've always felt that FM was most useful in it's html format, and then perhaps secondarily as an ePUB book export. So one follow-up question for Mick is whether the width restriction applies to ePUB format as well? I'm guessing it does, based on my ePUB version of the rewritten Audacity manual. Actually, now that I look at it closely, that ePUB suffers from many of the same formatting issues as the PDF--so I guess I won't go around showing that version to everybody ?. >> >> Meanwhile, though, Maren is correct: the restriction on image width (and resulting distortion) seems to disappear when you look at a published book in html format, or even "View Draft" of a book in progress from the main book page, e.g. http://write.flossmanuals.net/introduction-to-video-editing-with-shotcut/_info/ in the case of my new manual. This is interesting because the same 1366-width screenshot (see the Installing chapter) shows up distorted not just in the editor, but also when you hit "View Chapter" from within the editor, and expand that new window as much as possible. You have to "View Draft" from the main book page to see the image properly proportioned in that chapter. Btw, Maren's Inkscape book is absolutely gorgeous, but as far as I can tell most of the images there seem to actually stay within the 600 or 700 px limit. I did that myself with the Audacity book, in order to avoid what I thought was otherwise inescapable distortion. I have tons of screenshots but I sized my Audacity window itself as small as I felt I could, practically, and then generally just captured a particular panel or region or control area of it. I'll see to what extent that works for Shotcut too. 600 px is a pretty draconian limit for modern screenshots, though, as no one in their right might would use most of these editing tools at that width. I get that the print version needs some kind of image width limit. One would think that the "Constrain Proportions" function would at least, you know, constrain proportions if the image exceeded that limit, and simply show a smaller overall screenshot. But I can't get that to work in the editor: it seems to always take the actual height but constain the width. No doubt why they fixed it in 2.2... >> >> Matt >> >> >> From: Discuss > on behalf of Daniel James > >> Sent: Friday, February 9, 2018 5:41 AM >> To: mick at flossmanuals.net ; discuss at lists.flossmanuals.net >> Subject: Re: [FM Discuss] issues with Kdenlive manual images >> >> Hi Mick, >> >> > I know the limit used to be 600px wide and I have always stuck to that. >> >> Booktype has come a long way since those days :-) >> >> > I am pretty sure that this is a limit that has >> > increased in Booktype 2.x and also he might have more knowledge of what >> > happens if we use a wider images size in 1.6 and any potential hacks. >> >> In Booktype 2.3 you can use any image size you want, as long as the >> resolution is high enough for print output (should that be one of your >> targets). There are also tools for zooming, cropping etc. built in. >> >> Cheers! >> >> Daniel >> _______________________________________________ >> Discuss mailing list >> Discuss at lists.flossmanuals.net >> http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here >> Discuss Info Page - lists.flossmanuals.net >> lists.flossmanuals.net >> 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 ... >> >> >> _______________________________________________ >> Discuss mailing list >> Discuss at lists.flossmanuals.net >> http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here > > Check out Sea Serpent Design's cards and gifts ? > > ... at Zazzle: > ? > Ladybug Hearts Card > by rclord > ? > Dog King and Queen of Hearts > by rclord ... at Redbubble: > > > > _______________________________________________ > Discuss mailing list > Discuss at lists.flossmanuals.net > http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Check out Sea Serpent Design's cards and gifts ? ... at Zazzle: Ladybug Hearts Card by rclord Dog King and Queen of Hearts by rclord ... at Redbubble: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mick at flossmanuals.net Sat Feb 10 04:57:13 2018 From: mick at flossmanuals.net (mick at flossmanuals.net) Date: Sat, 10 Feb 2018 12:57:13 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> Message-ID: <8612cc38-b6c5-ffdf-2cf8-74301b26b341@flossmanuals.net> On 09/02/18 20:16, M R wrote: > 00 px is a pretty draconian limit for modern screenshots, though, as > no one in their right might would use most of these editing tools at > that width. I get that the print version needs some kind of image > width limit. One would think that the "Constrain Proportions" > function would at least, you know, constrain proportions if the image > exceeded that limit, and simply show a smaller overall screenshot. > But I can't get that to work in the editor: it seems to always take > the actual height but constain the width. No doubt why they fixed it > in 2.2... As Rosalind pointed out, I does seem to do that for the published version. But I have seen squished images in the editor too. So maybe we can work on a guideline for images width based on what they look like when they are outputted to pdf. 800px for me seems about right as above that it is hard to see what you want users to look at. For me although the challenge of drawing the attention to the most relevant part of the screen. Thanks Mick From matrobnew at hotmail.com Sat Feb 10 13:07:55 2018 From: matrobnew at hotmail.com (M R) Date: Sat, 10 Feb 2018 21:07:55 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: <8612cc38-b6c5-ffdf-2cf8-74301b26b341@flossmanuals.net> References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> , <8612cc38-b6c5-ffdf-2cf8-74301b26b341@flossmanuals.net> Message-ID: Mick: 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: 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. 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. 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. 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. 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 movingparts 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. 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. Best, Matt ________________________________ From: Discuss on behalf of mick at flossmanuals.net Sent: Saturday, February 10, 2018 5:57 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images On 09/02/18 20:16, M R wrote: > 00 px is a pretty draconian limit for modern screenshots, though, as > no one in their right might would use most of these editing tools at > that width. I get that the print version needs some kind of image > width limit. One would think that the "Constrain Proportions" > function would at least, you know, constrain proportions if the image > exceeded that limit, and simply show a smaller overall screenshot. > But I can't get that to work in the editor: it seems to always take > the actual height but constain the width. No doubt why they fixed it > in 2.2... As Rosalind pointed out, I does seem to do that for the published version. But I have seen squished images in the editor too. So maybe we can work on a guideline for images width based on what they look like when they are outputted to pdf. 800px for me seems about right as above that it is hard to see what you want users to look at. For me although the challenge of drawing the attention to the most relevant part of the screen. Thanks Mick _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Discuss Info Page - lists.flossmanuals.net lists.flossmanuals.net 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 ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.Chesterman at mmu.ac.uk Mon Feb 12 02:16:12 2018 From: M.Chesterman at mmu.ac.uk (Mick Chesterman) Date: Mon, 12 Feb 2018 10:16:12 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> , <8612cc38-b6c5-ffdf-2cf8-74301b26b341@flossmanuals.net>, Message-ID: <1518430572076.2439@mmu.ac.uk> Hi Matt, 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. And you make a good case for looking at different situations and using doc tools based on the most appropriate response. As far as the screen limit, at the moment, the css override is the following; img { border-style:none; max-width:800px; height: auto; } 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. This has been helpful for me to start up conversations to get moved to booktype 2 as well. Thanks Mick From: Discuss on behalf of M R Sent: 10 February 2018 21:07 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Mick: 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: 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. 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. 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. 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. 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 movingparts 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. 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. Best, Matt ________________________________ From: Discuss on behalf of mick at flossmanuals.net Sent: Saturday, February 10, 2018 5:57 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images On 09/02/18 20:16, M R wrote: > 00 px is a pretty draconian limit for modern screenshots, though, as > no one in their right might would use most of these editing tools at > that width. I get that the print version needs some kind of image > width limit. One would think that the "Constrain Proportions" > function would at least, you know, constrain proportions if the image > exceeded that limit, and simply show a smaller overall screenshot. > But I can't get that to work in the editor: it seems to always take > the actual height but constain the width. No doubt why they fixed it > in 2.2... As Rosalind pointed out, I does seem to do that for the published version. But I have seen squished images in the editor too. So maybe we can work on a guideline for images width based on what they look like when they are outputted to pdf. 800px for me seems about right as above that it is hard to see what you want users to look at. For me although the challenge of drawing the attention to the most relevant part of the screen. Thanks Mick _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Discuss Info Page - lists.flossmanuals.net lists.flossmanuals.net 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 ... "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: From matrobnew at hotmail.com Mon Feb 12 13:29:46 2018 From: matrobnew at hotmail.com (M R) Date: Mon, 12 Feb 2018 21:29:46 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: <1518430572076.2439@mmu.ac.uk> References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> , <8612cc38-b6c5-ffdf-2cf8-74301b26b341@flossmanuals.net>, , <1518430572076.2439@mmu.ac.uk> Message-ID: Hi Mick: 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. 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. 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. 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). best, Matt ________________________________ From: Discuss on behalf of Mick Chesterman Sent: Monday, February 12, 2018 3:16 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Matt, 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. And you make a good case for looking at different situations and using doc tools based on the most appropriate response. As far as the screen limit, at the moment, the css override is the following; img { border-style:none; max-width:800px; height: auto; } 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. This has been helpful for me to start up conversations to get moved to booktype 2 as well. Thanks Mick From: Discuss on behalf of M R Sent: 10 February 2018 21:07 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Mick: 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: 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. 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. 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. 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. 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 movingparts 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. 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. Best, Matt ________________________________ From: Discuss on behalf of mick at flossmanuals.net Sent: Saturday, February 10, 2018 5:57 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images On 09/02/18 20:16, M R wrote: > 00 px is a pretty draconian limit for modern screenshots, though, as > no one in their right might would use most of these editing tools at > that width. I get that the print version needs some kind of image > width limit. One would think that the "Constrain Proportions" > function would at least, you know, constrain proportions if the image > exceeded that limit, and simply show a smaller overall screenshot. > But I can't get that to work in the editor: it seems to always take > the actual height but constain the width. No doubt why they fixed it > in 2.2... As Rosalind pointed out, I does seem to do that for the published version. But I have seen squished images in the editor too. So maybe we can work on a guideline for images width based on what they look like when they are outputted to pdf. 800px for me seems about right as above that it is hard to see what you want users to look at. For me although the challenge of drawing the attention to the most relevant part of the screen. Thanks Mick _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Discuss Info Page - lists.flossmanuals.net lists.flossmanuals.net 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 ... "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Kean at op.ac.nz Mon Feb 12 16:37:36 2018 From: Martin.Kean at op.ac.nz (Martin Kean) Date: Tue, 13 Feb 2018 00:37:36 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> , <8612cc38-b6c5-ffdf-2cf8-74301b26b341@flossmanuals.net>, , <1518430572076.2439@mmu.ac.uk>, Message-ID: Hi there, I'm a little late to the conversation, but wondering if pixels are the best for width within device screens or for the printed page. I often use vw and vh, viewport width and viewport height: https://css-tricks.com/fun-viewport-units/ and here ... https://css-tricks.com/full-width-containers-limited-width-parents/ ... 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. I'm really getting into CSS Grid: https://css-tricks.com/snippets/css/complete-guide-grid/ http://jensimmons.com/post/feb-27-2017/learn-css-grid ... but this would be too long a stride out at this point, so I suggest viewport widths: img { border-style: none; border: 0; box-sizing: border-box; min-width: 80vw; /* 80% of the screen or page width, or whatever % you prefer */ max-width: 95vw; /* again, whatever % you prefer */ height: auto; } I'd like to work with anyone on this so please keep me in the loop. Thanks, Martin ________________________________ From: Discuss on behalf of M R Sent: Tuesday, 13 February 2018 10:29:46 a.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Mick: 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. 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. 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. 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). best, Matt ________________________________ From: Discuss on behalf of Mick Chesterman Sent: Monday, February 12, 2018 3:16 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Matt, 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. And you make a good case for looking at different situations and using doc tools based on the most appropriate response. As far as the screen limit, at the moment, the css override is the following; img { border-style:none; max-width:800px; height: auto; } 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. This has been helpful for me to start up conversations to get moved to booktype 2 as well. Thanks Mick From: Discuss on behalf of M R Sent: 10 February 2018 21:07 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Mick: 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: 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. 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. 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. 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. 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 movingparts 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. 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. Best, Matt ________________________________ From: Discuss on behalf of mick at flossmanuals.net Sent: Saturday, February 10, 2018 5:57 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images On 09/02/18 20:16, M R wrote: > 00 px is a pretty draconian limit for modern screenshots, though, as > no one in their right might would use most of these editing tools at > that width. I get that the print version needs some kind of image > width limit. One would think that the "Constrain Proportions" > function would at least, you know, constrain proportions if the image > exceeded that limit, and simply show a smaller overall screenshot. > But I can't get that to work in the editor: it seems to always take > the actual height but constain the width. No doubt why they fixed it > in 2.2... As Rosalind pointed out, I does seem to do that for the published version. But I have seen squished images in the editor too. So maybe we can work on a guideline for images width based on what they look like when they are outputted to pdf. 800px for me seems about right as above that it is hard to see what you want users to look at. For me although the challenge of drawing the attention to the most relevant part of the screen. Thanks Mick _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Discuss Info Page - lists.flossmanuals.net lists.flossmanuals.net 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 ... "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: From matrobnew at hotmail.com Mon Feb 12 18:47:28 2018 From: matrobnew at hotmail.com (M R) Date: Tue, 13 Feb 2018 02:47:28 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> , <8612cc38-b6c5-ffdf-2cf8-74301b26b341@flossmanuals.net>, , <1518430572076.2439@mmu.ac.uk>, , Message-ID: Martin: That sounds really interesting: I didn't know you could specify by viewport h and w % in CSS (though that's standard in lots of app authoring I've done, for e.g. Windows or Android apps). But then I know next to nothing about modern CSS; I basically got out of client-side web development as such in the early '00s. Mick, what do you think? To *some* degree it seems like going with viewport width (and height) % would address our issues--but then again, perhaps not completely. If I put in a 1300 px wide screenshot and our CSS, revised along the lines Martin suggests, rendered that as (say) 80% of someone's 800-pixel width screen, then the image would all fit in their screen, but the details would be tiny, probably too tiny to be useful. So we might still need some absolute limit on screenshot pixel width. The thing is, there is a whole galactic-sized industry of technical writing out there, still cranking out documentation with screenshots (despite my best efforts to move them toward video ?); so you'd think there would be best-practice guidelines well established around this very question. You would think. But in the google searching I've just done, while I've unearthed some very sensible articles/posts from individuals talking about what makes for better and worse screenshots, I get no sense at all of a widely-accepted standard width or resolution. If those standards are out there, they're embedded in full tech-writing courses and not seemingly accessible to googling. Everyone I've read agrees that screenshots should be PNG and not JPEG. Most people agree that PRNTSCRN is too blunt-force, at least without cropping, not least because it will inevitably capture personal screen details that are idiosyncratic and distracting, and irrelevant. Any tech-writing professional is presumably using some specialized screen capture software that allows for selection of a customized area or a specified app or window (the one I use even tries to pick out specific panes/windows within the software UI I'm demo-ing, which is great when it works). But none of this speaks to how large (and in what resolution) the captured area actually should be. The common-sense answer is: "large enough to show what you need to show, ie what is actually relevant to your demonstration." Mick, that was basically your original answer, and it's truly sound common sense; but then I would go right back to my original response to it. Maybe where that leaves us is the idea that, if the software you're trying to demonstrate really does require you to see, simultaneously, multiple panes of a UI stretching across, say, 1000+ pixels or more, then perhaps we're beyond the limits of the static text-and-screenshot genre of documentation anyway. So maybe we just kick the image-width limit up slightly, to 1000 (though that was a purely arbitrary number); or maybe we change the CSS to a % of viewport, but still establish a defacto max width of 1000 for FM screenshots. Or maybe the de facto standard should remain 800 px. Truly it beats me. I'm going to stay below 800 px for the duration of the Shotcut manual, anyway -- even though I'd be truly surprised if many Shotcut users actually confined themselves to that little real estate in using the tool. Btw, here's some survey data on display sizes and their historical trend, from a pretty established source: https://www.w3schools.com/browsers/browsers_display.asp OTOH, the typical FM manual consumer might be a lot more old-school than the median of these trends. Best, Matt ________________________________ From: Discuss on behalf of Martin Kean Sent: Monday, February 12, 2018 5:37 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi there, I'm a little late to the conversation, but wondering if pixels are the best for width within device screens or for the printed page. I often use vw and vh, viewport width and viewport height: https://css-tricks.com/fun-viewport-units/ and here ... https://css-tricks.com/full-width-containers-limited-width-parents/ ... 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. I'm really getting into CSS Grid: https://css-tricks.com/snippets/css/complete-guide-grid/ http://jensimmons.com/post/feb-27-2017/learn-css-grid ... but this would be too long a stride out at this point, so I suggest viewport widths: img { border-style: none; border: 0; box-sizing: border-box; min-width: 80vw; /* 80% of the screen or page width, or whatever % you prefer */ max-width: 95vw; /* again, whatever % you prefer */ height: auto; } I'd like to work with anyone on this so please keep me in the loop. Thanks, Martin ________________________________ From: Discuss on behalf of M R Sent: Tuesday, 13 February 2018 10:29:46 a.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Mick: 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. 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. 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. 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). best, Matt ________________________________ From: Discuss on behalf of Mick Chesterman Sent: Monday, February 12, 2018 3:16 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Matt, 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. And you make a good case for looking at different situations and using doc tools based on the most appropriate response. As far as the screen limit, at the moment, the css override is the following; img { border-style:none; max-width:800px; height: auto; } 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. This has been helpful for me to start up conversations to get moved to booktype 2 as well. Thanks Mick From: Discuss on behalf of M R Sent: 10 February 2018 21:07 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Mick: 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: 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. 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. 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. 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. 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 movingparts 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. 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. Best, Matt ________________________________ From: Discuss on behalf of mick at flossmanuals.net Sent: Saturday, February 10, 2018 5:57 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images On 09/02/18 20:16, M R wrote: > 00 px is a pretty draconian limit for modern screenshots, though, as > no one in their right might would use most of these editing tools at > that width. I get that the print version needs some kind of image > width limit. One would think that the "Constrain Proportions" > function would at least, you know, constrain proportions if the image > exceeded that limit, and simply show a smaller overall screenshot. > But I can't get that to work in the editor: it seems to always take > the actual height but constain the width. No doubt why they fixed it > in 2.2... As Rosalind pointed out, I does seem to do that for the published version. But I have seen squished images in the editor too. So maybe we can work on a guideline for images width based on what they look like when they are outputted to pdf. 800px for me seems about right as above that it is hard to see what you want users to look at. For me although the challenge of drawing the attention to the most relevant part of the screen. Thanks Mick _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Discuss Info Page - lists.flossmanuals.net lists.flossmanuals.net 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 ... "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Kean at op.ac.nz Mon Feb 12 18:58:17 2018 From: Martin.Kean at op.ac.nz (Martin Kean) Date: Tue, 13 Feb 2018 02:58:17 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> , <8612cc38-b6c5-ffdf-2cf8-74301b26b341@flossmanuals.net>, , <1518430572076.2439@mmu.ac.uk>, , , Message-ID: Hi Matt, "... it seems like going with viewport width (and height) % would address our issues--but then again, perhaps not completely. If I put in a 1300 px wide screenshot and our CSS, revised along the lines Martin suggests, rendered that as (say) 80% of someone's 800-pixel width screen, then the image would all fit in their screen, but the details would be tiny, probably too tiny to be useful. So we might still need some absolute limit on screenshot pixel width." What about treating images on a case-by-case basis, this would mean descriptive CSS class names when inserting images, so for example: "Everyone I've read agrees that screenshots should be PNG and not JPEG." I recommend JPEG for photo-like images, whereas PNG is best for images that contain text that needs to be readable (PNG preserves shape edges to a degree) Cheers, Martin ________________________________ From: Discuss on behalf of M R Sent: Tuesday, 13 February 2018 3:47:28 p.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Martin: That sounds really interesting: I didn't know you could specify by viewport h and w % in CSS (though that's standard in lots of app authoring I've done, for e.g. Windows or Android apps). But then I know next to nothing about modern CSS; I basically got out of client-side web development as such in the early '00s. Mick, what do you think? To *some* degree it seems like going with viewport width (and height) % would address our issues--but then again, perhaps not completely. If I put in a 1300 px wide screenshot and our CSS, revised along the lines Martin suggests, rendered that as (say) 80% of someone's 800-pixel width screen, then the image would all fit in their screen, but the details would be tiny, probably too tiny to be useful. So we might still need some absolute limit on screenshot pixel width. The thing is, there is a whole galactic-sized industry of technical writing out there, still cranking out documentation with screenshots (despite my best efforts to move them toward video ?); so you'd think there would be best-practice guidelines well established around this very question. You would think. But in the google searching I've just done, while I've unearthed some very sensible articles/posts from individuals talking about what makes for better and worse screenshots, I get no sense at all of a widely-accepted standard width or resolution. If those standards are out there, they're embedded in full tech-writing courses and not seemingly accessible to googling. Everyone I've read agrees that screenshots should be PNG and not JPEG. Most people agree that PRNTSCRN is too blunt-force, at least without cropping, not least because it will inevitably capture personal screen details that are idiosyncratic and distracting, and irrelevant. Any tech-writing professional is presumably using some specialized screen capture software that allows for selection of a customized area or a specified app or window (the one I use even tries to pick out specific panes/windows within the software UI I'm demo-ing, which is great when it works). But none of this speaks to how large (and in what resolution) the captured area actually should be. The common-sense answer is: "large enough to show what you need to show, ie what is actually relevant to your demonstration." Mick, that was basically your original answer, and it's truly sound common sense; but then I would go right back to my original response to it. Maybe where that leaves us is the idea that, if the software you're trying to demonstrate really does require you to see, simultaneously, multiple panes of a UI stretching across, say, 1000+ pixels or more, then perhaps we're beyond the limits of the static text-and-screenshot genre of documentation anyway. So maybe we just kick the image-width limit up slightly, to 1000 (though that was a purely arbitrary number); or maybe we change the CSS to a % of viewport, but still establish a defacto max width of 1000 for FM screenshots. Or maybe the de facto standard should remain 800 px. Truly it beats me. I'm going to stay below 800 px for the duration of the Shotcut manual, anyway -- even though I'd be truly surprised if many Shotcut users actually confined themselves to that little real estate in using the tool. Btw, here's some survey data on display sizes and their historical trend, from a pretty established source: https://www.w3schools.com/browsers/browsers_display.asp OTOH, the typical FM manual consumer might be a lot more old-school than the median of these trends. Best, Matt ________________________________ From: Discuss on behalf of Martin Kean Sent: Monday, February 12, 2018 5:37 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi there, I'm a little late to the conversation, but wondering if pixels are the best for width within device screens or for the printed page. I often use vw and vh, viewport width and viewport height: https://css-tricks.com/fun-viewport-units/ and here ... https://css-tricks.com/full-width-containers-limited-width-parents/ ... 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. I'm really getting into CSS Grid: https://css-tricks.com/snippets/css/complete-guide-grid/ http://jensimmons.com/post/feb-27-2017/learn-css-grid ... but this would be too long a stride out at this point, so I suggest viewport widths: img { border-style: none; border: 0; box-sizing: border-box; min-width: 80vw; /* 80% of the screen or page width, or whatever % you prefer */ max-width: 95vw; /* again, whatever % you prefer */ height: auto; } I'd like to work with anyone on this so please keep me in the loop. Thanks, Martin ________________________________ From: Discuss on behalf of M R Sent: Tuesday, 13 February 2018 10:29:46 a.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Mick: 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. 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. 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. 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). best, Matt ________________________________ From: Discuss on behalf of Mick Chesterman Sent: Monday, February 12, 2018 3:16 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Matt, 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. And you make a good case for looking at different situations and using doc tools based on the most appropriate response. As far as the screen limit, at the moment, the css override is the following; img { border-style:none; max-width:800px; height: auto; } 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. This has been helpful for me to start up conversations to get moved to booktype 2 as well. Thanks Mick From: Discuss on behalf of M R Sent: 10 February 2018 21:07 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Mick: 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: 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. 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. 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. 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. 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 movingparts 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. 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. Best, Matt ________________________________ From: Discuss on behalf of mick at flossmanuals.net Sent: Saturday, February 10, 2018 5:57 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images On 09/02/18 20:16, M R wrote: > 00 px is a pretty draconian limit for modern screenshots, though, as > no one in their right might would use most of these editing tools at > that width. I get that the print version needs some kind of image > width limit. One would think that the "Constrain Proportions" > function would at least, you know, constrain proportions if the image > exceeded that limit, and simply show a smaller overall screenshot. > But I can't get that to work in the editor: it seems to always take > the actual height but constain the width. No doubt why they fixed it > in 2.2... As Rosalind pointed out, I does seem to do that for the published version. But I have seen squished images in the editor too. So maybe we can work on a guideline for images width based on what they look like when they are outputted to pdf. 800px for me seems about right as above that it is hard to see what you want users to look at. For me although the challenge of drawing the attention to the most relevant part of the screen. Thanks Mick _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Discuss Info Page - lists.flossmanuals.net lists.flossmanuals.net 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 ... "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: From matrobnew at hotmail.com Mon Feb 12 19:16:14 2018 From: matrobnew at hotmail.com (M R) Date: Tue, 13 Feb 2018 03:16:14 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> , <8612cc38-b6c5-ffdf-2cf8-74301b26b341@flossmanuals.net>, , <1518430572076.2439@mmu.ac.uk>, , , , Message-ID: Martin: So, to be clear, taking your idea of case-by-case: if I felt I truly needed something like a 1400 px screenshot, I could specify, say, 130% viewport width, rather than the standard 80%, and then people with smaller screens would just get a scrollbar? But...if you are working with viewport w and h %, is that a maximum for IF your browser can't accept the full image in it's original size? Or does it instead establish a fixed %, regardless of window size? Because I'd hate to enforce a massive screenshot image, and a scrollbar, for people who already have large enough windows to accommodate the full image size (which I remain convinced would be the majority). I'm thinking we may need something like <100% viewport width, specified globally in CSS, in conjunction with some kind of de facto px limit for screenshots. Though I may just not be understanding your proposal. Matt ________________________________ From: Discuss on behalf of Martin Kean Sent: Monday, February 12, 2018 7:58 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Matt, "... it seems like going with viewport width (and height) % would address our issues--but then again, perhaps not completely. If I put in a 1300 px wide screenshot and our CSS, revised along the lines Martin suggests, rendered that as (say) 80% of someone's 800-pixel width screen, then the image would all fit in their screen, but the details would be tiny, probably too tiny to be useful. So we might still need some absolute limit on screenshot pixel width." What about treating images on a case-by-case basis, this would mean descriptive CSS class names when inserting images, so for example: "Everyone I've read agrees that screenshots should be PNG and not JPEG." I recommend JPEG for photo-like images, whereas PNG is best for images that contain text that needs to be readable (PNG preserves shape edges to a degree) Cheers, Martin ________________________________ From: Discuss on behalf of M R Sent: Tuesday, 13 February 2018 3:47:28 p.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Martin: That sounds really interesting: I didn't know you could specify by viewport h and w % in CSS (though that's standard in lots of app authoring I've done, for e.g. Windows or Android apps). But then I know next to nothing about modern CSS; I basically got out of client-side web development as such in the early '00s. Mick, what do you think? To *some* degree it seems like going with viewport width (and height) % would address our issues--but then again, perhaps not completely. If I put in a 1300 px wide screenshot and our CSS, revised along the lines Martin suggests, rendered that as (say) 80% of someone's 800-pixel width screen, then the image would all fit in their screen, but the details would be tiny, probably too tiny to be useful. So we might still need some absolute limit on screenshot pixel width. The thing is, there is a whole galactic-sized industry of technical writing out there, still cranking out documentation with screenshots (despite my best efforts to move them toward video ?); so you'd think there would be best-practice guidelines well established around this very question. You would think. But in the google searching I've just done, while I've unearthed some very sensible articles/posts from individuals talking about what makes for better and worse screenshots, I get no sense at all of a widely-accepted standard width or resolution. If those standards are out there, they're embedded in full tech-writing courses and not seemingly accessible to googling. Everyone I've read agrees that screenshots should be PNG and not JPEG. Most people agree that PRNTSCRN is too blunt-force, at least without cropping, not least because it will inevitably capture personal screen details that are idiosyncratic and distracting, and irrelevant. Any tech-writing professional is presumably using some specialized screen capture software that allows for selection of a customized area or a specified app or window (the one I use even tries to pick out specific panes/windows within the software UI I'm demo-ing, which is great when it works). But none of this speaks to how large (and in what resolution) the captured area actually should be. The common-sense answer is: "large enough to show what you need to show, ie what is actually relevant to your demonstration." Mick, that was basically your original answer, and it's truly sound common sense; but then I would go right back to my original response to it. Maybe where that leaves us is the idea that, if the software you're trying to demonstrate really does require you to see, simultaneously, multiple panes of a UI stretching across, say, 1000+ pixels or more, then perhaps we're beyond the limits of the static text-and-screenshot genre of documentation anyway. So maybe we just kick the image-width limit up slightly, to 1000 (though that was a purely arbitrary number); or maybe we change the CSS to a % of viewport, but still establish a defacto max width of 1000 for FM screenshots. Or maybe the de facto standard should remain 800 px. Truly it beats me. I'm going to stay below 800 px for the duration of the Shotcut manual, anyway -- even though I'd be truly surprised if many Shotcut users actually confined themselves to that little real estate in using the tool. Btw, here's some survey data on display sizes and their historical trend, from a pretty established source: https://www.w3schools.com/browsers/browsers_display.asp OTOH, the typical FM manual consumer might be a lot more old-school than the median of these trends. Best, Matt ________________________________ From: Discuss on behalf of Martin Kean Sent: Monday, February 12, 2018 5:37 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi there, I'm a little late to the conversation, but wondering if pixels are the best for width within device screens or for the printed page. I often use vw and vh, viewport width and viewport height: https://css-tricks.com/fun-viewport-units/ and here ... https://css-tricks.com/full-width-containers-limited-width-parents/ ... 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. I'm really getting into CSS Grid: https://css-tricks.com/snippets/css/complete-guide-grid/ http://jensimmons.com/post/feb-27-2017/learn-css-grid ... but this would be too long a stride out at this point, so I suggest viewport widths: img { border-style: none; border: 0; box-sizing: border-box; min-width: 80vw; /* 80% of the screen or page width, or whatever % you prefer */ max-width: 95vw; /* again, whatever % you prefer */ height: auto; } I'd like to work with anyone on this so please keep me in the loop. Thanks, Martin ________________________________ From: Discuss on behalf of M R Sent: Tuesday, 13 February 2018 10:29:46 a.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Mick: 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. 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. 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. 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). best, Matt ________________________________ From: Discuss on behalf of Mick Chesterman Sent: Monday, February 12, 2018 3:16 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Matt, 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. And you make a good case for looking at different situations and using doc tools based on the most appropriate response. As far as the screen limit, at the moment, the css override is the following; img { border-style:none; max-width:800px; height: auto; } 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. This has been helpful for me to start up conversations to get moved to booktype 2 as well. Thanks Mick From: Discuss on behalf of M R Sent: 10 February 2018 21:07 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Mick: 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: 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. 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. 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. 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. 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 movingparts 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. 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. Best, Matt ________________________________ From: Discuss on behalf of mick at flossmanuals.net Sent: Saturday, February 10, 2018 5:57 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images On 09/02/18 20:16, M R wrote: > 00 px is a pretty draconian limit for modern screenshots, though, as > no one in their right might would use most of these editing tools at > that width. I get that the print version needs some kind of image > width limit. One would think that the "Constrain Proportions" > function would at least, you know, constrain proportions if the image > exceeded that limit, and simply show a smaller overall screenshot. > But I can't get that to work in the editor: it seems to always take > the actual height but constain the width. No doubt why they fixed it > in 2.2... As Rosalind pointed out, I does seem to do that for the published version. But I have seen squished images in the editor too. So maybe we can work on a guideline for images width based on what they look like when they are outputted to pdf. 800px for me seems about right as above that it is hard to see what you want users to look at. For me although the challenge of drawing the attention to the most relevant part of the screen. Thanks Mick _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Discuss Info Page - lists.flossmanuals.net lists.flossmanuals.net 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 ... "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Kean at op.ac.nz Mon Feb 12 20:22:46 2018 From: Martin.Kean at op.ac.nz (Martin Kean) Date: Tue, 13 Feb 2018 04:22:46 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> , <8612cc38-b6c5-ffdf-2cf8-74301b26b341@flossmanuals.net>, , <1518430572076.2439@mmu.ac.uk>, , , , , Message-ID: Hi Matt, Yup, so, "if I felt I truly needed something like a 1400 px screenshot, I could specify, say, 130% viewport width," Here, in the example below, the image gracefully scales to the viewport width, but when the width narrows to less than 460px, the minimum width becomes twice the width of the viewport (200vw) CSS: img { display: block; } .fullest-width { box-sizing: border-box; margin: 0; width: 100vw; height: auto; } .gracefully { -webkit-transition: all 0.3s ease-out; transition: all 0.3s ease-out; } @media screen and (max-width: 460px) { .fullest-width { min-width: 200vw; overflow: visible; } } HTML:
Does that work? Cheers, Martin ________________________________ From: Discuss on behalf of M R Sent: Tuesday, 13 February 2018 4:16:14 p.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Martin: So, to be clear, taking your idea of case-by-case: if I felt I truly needed something like a 1400 px screenshot, I could specify, say, 130% viewport width, rather than the standard 80%, and then people with smaller screens would just get a scrollbar? But...if you are working with viewport w and h %, is that a maximum for IF your browser can't accept the full image in it's original size? Or does it instead establish a fixed %, regardless of window size? Because I'd hate to enforce a massive screenshot image, and a scrollbar, for people who already have large enough windows to accommodate the full image size (which I remain convinced would be the majority). I'm thinking we may need something like <100% viewport width, specified globally in CSS, in conjunction with some kind of de facto px limit for screenshots. Though I may just not be understanding your proposal. Matt ________________________________ From: Discuss on behalf of Martin Kean Sent: Monday, February 12, 2018 7:58 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Matt, "... it seems like going with viewport width (and height) % would address our issues--but then again, perhaps not completely. If I put in a 1300 px wide screenshot and our CSS, revised along the lines Martin suggests, rendered that as (say) 80% of someone's 800-pixel width screen, then the image would all fit in their screen, but the details would be tiny, probably too tiny to be useful. So we might still need some absolute limit on screenshot pixel width." What about treating images on a case-by-case basis, this would mean descriptive CSS class names when inserting images, so for example: "Everyone I've read agrees that screenshots should be PNG and not JPEG." I recommend JPEG for photo-like images, whereas PNG is best for images that contain text that needs to be readable (PNG preserves shape edges to a degree) Cheers, Martin ________________________________ From: Discuss on behalf of M R Sent: Tuesday, 13 February 2018 3:47:28 p.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Martin: That sounds really interesting: I didn't know you could specify by viewport h and w % in CSS (though that's standard in lots of app authoring I've done, for e.g. Windows or Android apps). But then I know next to nothing about modern CSS; I basically got out of client-side web development as such in the early '00s. Mick, what do you think? To *some* degree it seems like going with viewport width (and height) % would address our issues--but then again, perhaps not completely. If I put in a 1300 px wide screenshot and our CSS, revised along the lines Martin suggests, rendered that as (say) 80% of someone's 800-pixel width screen, then the image would all fit in their screen, but the details would be tiny, probably too tiny to be useful. So we might still need some absolute limit on screenshot pixel width. The thing is, there is a whole galactic-sized industry of technical writing out there, still cranking out documentation with screenshots (despite my best efforts to move them toward video ?); so you'd think there would be best-practice guidelines well established around this very question. You would think. But in the google searching I've just done, while I've unearthed some very sensible articles/posts from individuals talking about what makes for better and worse screenshots, I get no sense at all of a widely-accepted standard width or resolution. If those standards are out there, they're embedded in full tech-writing courses and not seemingly accessible to googling. Everyone I've read agrees that screenshots should be PNG and not JPEG. Most people agree that PRNTSCRN is too blunt-force, at least without cropping, not least because it will inevitably capture personal screen details that are idiosyncratic and distracting, and irrelevant. Any tech-writing professional is presumably using some specialized screen capture software that allows for selection of a customized area or a specified app or window (the one I use even tries to pick out specific panes/windows within the software UI I'm demo-ing, which is great when it works). But none of this speaks to how large (and in what resolution) the captured area actually should be. The common-sense answer is: "large enough to show what you need to show, ie what is actually relevant to your demonstration." Mick, that was basically your original answer, and it's truly sound common sense; but then I would go right back to my original response to it. Maybe where that leaves us is the idea that, if the software you're trying to demonstrate really does require you to see, simultaneously, multiple panes of a UI stretching across, say, 1000+ pixels or more, then perhaps we're beyond the limits of the static text-and-screenshot genre of documentation anyway. So maybe we just kick the image-width limit up slightly, to 1000 (though that was a purely arbitrary number); or maybe we change the CSS to a % of viewport, but still establish a defacto max width of 1000 for FM screenshots. Or maybe the de facto standard should remain 800 px. Truly it beats me. I'm going to stay below 800 px for the duration of the Shotcut manual, anyway -- even though I'd be truly surprised if many Shotcut users actually confined themselves to that little real estate in using the tool. Btw, here's some survey data on display sizes and their historical trend, from a pretty established source: https://www.w3schools.com/browsers/browsers_display.asp OTOH, the typical FM manual consumer might be a lot more old-school than the median of these trends. Best, Matt ________________________________ From: Discuss on behalf of Martin Kean Sent: Monday, February 12, 2018 5:37 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi there, I'm a little late to the conversation, but wondering if pixels are the best for width within device screens or for the printed page. I often use vw and vh, viewport width and viewport height: https://css-tricks.com/fun-viewport-units/ and here ... https://css-tricks.com/full-width-containers-limited-width-parents/ ... 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. I'm really getting into CSS Grid: https://css-tricks.com/snippets/css/complete-guide-grid/ http://jensimmons.com/post/feb-27-2017/learn-css-grid ... but this would be too long a stride out at this point, so I suggest viewport widths: img { border-style: none; border: 0; box-sizing: border-box; min-width: 80vw; /* 80% of the screen or page width, or whatever % you prefer */ max-width: 95vw; /* again, whatever % you prefer */ height: auto; } I'd like to work with anyone on this so please keep me in the loop. Thanks, Martin ________________________________ From: Discuss on behalf of M R Sent: Tuesday, 13 February 2018 10:29:46 a.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Mick: 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. 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. 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. 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). best, Matt ________________________________ From: Discuss on behalf of Mick Chesterman Sent: Monday, February 12, 2018 3:16 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Matt, 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. And you make a good case for looking at different situations and using doc tools based on the most appropriate response. As far as the screen limit, at the moment, the css override is the following; img { border-style:none; max-width:800px; height: auto; } 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. This has been helpful for me to start up conversations to get moved to booktype 2 as well. Thanks Mick From: Discuss on behalf of M R Sent: 10 February 2018 21:07 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Mick: 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: 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. 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. 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. 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. 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 movingparts 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. 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. Best, Matt ________________________________ From: Discuss on behalf of mick at flossmanuals.net Sent: Saturday, February 10, 2018 5:57 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images On 09/02/18 20:16, M R wrote: > 00 px is a pretty draconian limit for modern screenshots, though, as > no one in their right might would use most of these editing tools at > that width. I get that the print version needs some kind of image > width limit. One would think that the "Constrain Proportions" > function would at least, you know, constrain proportions if the image > exceeded that limit, and simply show a smaller overall screenshot. > But I can't get that to work in the editor: it seems to always take > the actual height but constain the width. No doubt why they fixed it > in 2.2... As Rosalind pointed out, I does seem to do that for the published version. But I have seen squished images in the editor too. So maybe we can work on a guideline for images width based on what they look like when they are outputted to pdf. 800px for me seems about right as above that it is hard to see what you want users to look at. For me although the challenge of drawing the attention to the most relevant part of the screen. Thanks Mick _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Discuss Info Page - lists.flossmanuals.net lists.flossmanuals.net 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 ... "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: From matrobnew at hotmail.com Mon Feb 12 21:20:07 2018 From: matrobnew at hotmail.com (M R) Date: Tue, 13 Feb 2018 05:20:07 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> , <8612cc38-b6c5-ffdf-2cf8-74301b26b341@flossmanuals.net>, , <1518430572076.2439@mmu.ac.uk>, , , , , , Message-ID: well, it looks gorgeous -- I was thinking I could do that in js, but CSS has clearly come a long way. I guess the question is how much freedom we have to manipulate the CSS at FM, either globally or (especially) case-by-case. Would your solution work as a global? I love, in any case, that ''gracefully" is an actual word in CSS now... matt ________________________________ From: Discuss on behalf of Martin Kean Sent: Monday, February 12, 2018 9:22 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Matt, Yup, so, "if I felt I truly needed something like a 1400 px screenshot, I could specify, say, 130% viewport width," Here, in the example below, the image gracefully scales to the viewport width, but when the width narrows to less than 460px, the minimum width becomes twice the width of the viewport (200vw) CSS: img { display: block; } .fullest-width { box-sizing: border-box; margin: 0; width: 100vw; height: auto; } .gracefully { -webkit-transition: all 0.3s ease-out; transition: all 0.3s ease-out; } @media screen and (max-width: 460px) { .fullest-width { min-width: 200vw; overflow: visible; } } HTML:
Does that work? Cheers, Martin ________________________________ From: Discuss on behalf of M R Sent: Tuesday, 13 February 2018 4:16:14 p.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Martin: So, to be clear, taking your idea of case-by-case: if I felt I truly needed something like a 1400 px screenshot, I could specify, say, 130% viewport width, rather than the standard 80%, and then people with smaller screens would just get a scrollbar? But...if you are working with viewport w and h %, is that a maximum for IF your browser can't accept the full image in it's original size? Or does it instead establish a fixed %, regardless of window size? Because I'd hate to enforce a massive screenshot image, and a scrollbar, for people who already have large enough windows to accommodate the full image size (which I remain convinced would be the majority). I'm thinking we may need something like <100% viewport width, specified globally in CSS, in conjunction with some kind of de facto px limit for screenshots. Though I may just not be understanding your proposal. Matt ________________________________ From: Discuss on behalf of Martin Kean Sent: Monday, February 12, 2018 7:58 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Matt, "... it seems like going with viewport width (and height) % would address our issues--but then again, perhaps not completely. If I put in a 1300 px wide screenshot and our CSS, revised along the lines Martin suggests, rendered that as (say) 80% of someone's 800-pixel width screen, then the image would all fit in their screen, but the details would be tiny, probably too tiny to be useful. So we might still need some absolute limit on screenshot pixel width." What about treating images on a case-by-case basis, this would mean descriptive CSS class names when inserting images, so for example: "Everyone I've read agrees that screenshots should be PNG and not JPEG." I recommend JPEG for photo-like images, whereas PNG is best for images that contain text that needs to be readable (PNG preserves shape edges to a degree) Cheers, Martin ________________________________ From: Discuss on behalf of M R Sent: Tuesday, 13 February 2018 3:47:28 p.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Martin: That sounds really interesting: I didn't know you could specify by viewport h and w % in CSS (though that's standard in lots of app authoring I've done, for e.g. Windows or Android apps). But then I know next to nothing about modern CSS; I basically got out of client-side web development as such in the early '00s. Mick, what do you think? To *some* degree it seems like going with viewport width (and height) % would address our issues--but then again, perhaps not completely. If I put in a 1300 px wide screenshot and our CSS, revised along the lines Martin suggests, rendered that as (say) 80% of someone's 800-pixel width screen, then the image would all fit in their screen, but the details would be tiny, probably too tiny to be useful. So we might still need some absolute limit on screenshot pixel width. The thing is, there is a whole galactic-sized industry of technical writing out there, still cranking out documentation with screenshots (despite my best efforts to move them toward video ?); so you'd think there would be best-practice guidelines well established around this very question. You would think. But in the google searching I've just done, while I've unearthed some very sensible articles/posts from individuals talking about what makes for better and worse screenshots, I get no sense at all of a widely-accepted standard width or resolution. If those standards are out there, they're embedded in full tech-writing courses and not seemingly accessible to googling. Everyone I've read agrees that screenshots should be PNG and not JPEG. Most people agree that PRNTSCRN is too blunt-force, at least without cropping, not least because it will inevitably capture personal screen details that are idiosyncratic and distracting, and irrelevant. Any tech-writing professional is presumably using some specialized screen capture software that allows for selection of a customized area or a specified app or window (the one I use even tries to pick out specific panes/windows within the software UI I'm demo-ing, which is great when it works). But none of this speaks to how large (and in what resolution) the captured area actually should be. The common-sense answer is: "large enough to show what you need to show, ie what is actually relevant to your demonstration." Mick, that was basically your original answer, and it's truly sound common sense; but then I would go right back to my original response to it. Maybe where that leaves us is the idea that, if the software you're trying to demonstrate really does require you to see, simultaneously, multiple panes of a UI stretching across, say, 1000+ pixels or more, then perhaps we're beyond the limits of the static text-and-screenshot genre of documentation anyway. So maybe we just kick the image-width limit up slightly, to 1000 (though that was a purely arbitrary number); or maybe we change the CSS to a % of viewport, but still establish a defacto max width of 1000 for FM screenshots. Or maybe the de facto standard should remain 800 px. Truly it beats me. I'm going to stay below 800 px for the duration of the Shotcut manual, anyway -- even though I'd be truly surprised if many Shotcut users actually confined themselves to that little real estate in using the tool. Btw, here's some survey data on display sizes and their historical trend, from a pretty established source: https://www.w3schools.com/browsers/browsers_display.asp OTOH, the typical FM manual consumer might be a lot more old-school than the median of these trends. Best, Matt ________________________________ From: Discuss on behalf of Martin Kean Sent: Monday, February 12, 2018 5:37 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi there, I'm a little late to the conversation, but wondering if pixels are the best for width within device screens or for the printed page. I often use vw and vh, viewport width and viewport height: https://css-tricks.com/fun-viewport-units/ and here ... https://css-tricks.com/full-width-containers-limited-width-parents/ ... 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. I'm really getting into CSS Grid: https://css-tricks.com/snippets/css/complete-guide-grid/ http://jensimmons.com/post/feb-27-2017/learn-css-grid ... but this would be too long a stride out at this point, so I suggest viewport widths: img { border-style: none; border: 0; box-sizing: border-box; min-width: 80vw; /* 80% of the screen or page width, or whatever % you prefer */ max-width: 95vw; /* again, whatever % you prefer */ height: auto; } I'd like to work with anyone on this so please keep me in the loop. Thanks, Martin ________________________________ From: Discuss on behalf of M R Sent: Tuesday, 13 February 2018 10:29:46 a.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Mick: 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. 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. 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. 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). best, Matt ________________________________ From: Discuss on behalf of Mick Chesterman Sent: Monday, February 12, 2018 3:16 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Matt, 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. And you make a good case for looking at different situations and using doc tools based on the most appropriate response. As far as the screen limit, at the moment, the css override is the following; img { border-style:none; max-width:800px; height: auto; } 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. This has been helpful for me to start up conversations to get moved to booktype 2 as well. Thanks Mick From: Discuss on behalf of M R Sent: 10 February 2018 21:07 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Mick: 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: 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. 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. 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. 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. 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 movingparts 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. 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. Best, Matt ________________________________ From: Discuss on behalf of mick at flossmanuals.net Sent: Saturday, February 10, 2018 5:57 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images On 09/02/18 20:16, M R wrote: > 00 px is a pretty draconian limit for modern screenshots, though, as > no one in their right might would use most of these editing tools at > that width. I get that the print version needs some kind of image > width limit. One would think that the "Constrain Proportions" > function would at least, you know, constrain proportions if the image > exceeded that limit, and simply show a smaller overall screenshot. > But I can't get that to work in the editor: it seems to always take > the actual height but constain the width. No doubt why they fixed it > in 2.2... As Rosalind pointed out, I does seem to do that for the published version. But I have seen squished images in the editor too. So maybe we can work on a guideline for images width based on what they look like when they are outputted to pdf. 800px for me seems about right as above that it is hard to see what you want users to look at. For me although the challenge of drawing the attention to the most relevant part of the screen. Thanks Mick _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Discuss Info Page - lists.flossmanuals.net lists.flossmanuals.net 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 ... "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Kean at op.ac.nz Mon Feb 12 22:41:38 2018 From: Martin.Kean at op.ac.nz (Martin Kean) Date: Tue, 13 Feb 2018 06:41:38 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: <129ef95084b64f1c8b4c7d61a4dfc6c7@BFEX02.ad.mmu.ac.uk> <458b57af-f197-028f-b4da-fc72cb13a457@booktype.org> , <8612cc38-b6c5-ffdf-2cf8-74301b26b341@flossmanuals.net>, , <1518430572076.2439@mmu.ac.uk>, , , , , , , Message-ID: Mick is there a place on the server to store global CSS stylesheets? If so, then could we have a GitLab repo, and link to (in the meantime) the stylesheets from Objavi using @import url("full-width-images-global-styles.css"); for example? Matt, ''gracefully" is not an actual CSS word, I've just used it here as a class name. Working example here: https://martinkean.com/img-test.html ; Martin ________________________________ From: Discuss on behalf of M R Sent: Tuesday, 13 February 2018 6:20:07 p.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images well, it looks gorgeous -- I was thinking I could do that in js, but CSS has clearly come a long way. I guess the question is how much freedom we have to manipulate the CSS at FM, either globally or (especially) case-by-case. Would your solution work as a global? I love, in any case, that ''gracefully" is an actual word in CSS now... matt ________________________________ From: Discuss on behalf of Martin Kean Sent: Monday, February 12, 2018 9:22 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Matt, Yup, so, "if I felt I truly needed something like a 1400 px screenshot, I could specify, say, 130% viewport width," Here, in the example below, the image gracefully scales to the viewport width, but when the width narrows to less than 460px, the minimum width becomes twice the width of the viewport (200vw) CSS: img { display: block; } .fullest-width { box-sizing: border-box; margin: 0; width: 100vw; height: auto; } .gracefully { -webkit-transition: all 0.3s ease-out; transition: all 0.3s ease-out; } @media screen and (max-width: 460px) { .fullest-width { min-width: 200vw; overflow: visible; } } HTML:
Does that work? Cheers, Martin ________________________________ From: Discuss on behalf of M R Sent: Tuesday, 13 February 2018 4:16:14 p.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Martin: So, to be clear, taking your idea of case-by-case: if I felt I truly needed something like a 1400 px screenshot, I could specify, say, 130% viewport width, rather than the standard 80%, and then people with smaller screens would just get a scrollbar? But...if you are working with viewport w and h %, is that a maximum for IF your browser can't accept the full image in it's original size? Or does it instead establish a fixed %, regardless of window size? Because I'd hate to enforce a massive screenshot image, and a scrollbar, for people who already have large enough windows to accommodate the full image size (which I remain convinced would be the majority). I'm thinking we may need something like <100% viewport width, specified globally in CSS, in conjunction with some kind of de facto px limit for screenshots. Though I may just not be understanding your proposal. Matt ________________________________ From: Discuss on behalf of Martin Kean Sent: Monday, February 12, 2018 7:58 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Matt, "... it seems like going with viewport width (and height) % would address our issues--but then again, perhaps not completely. If I put in a 1300 px wide screenshot and our CSS, revised along the lines Martin suggests, rendered that as (say) 80% of someone's 800-pixel width screen, then the image would all fit in their screen, but the details would be tiny, probably too tiny to be useful. So we might still need some absolute limit on screenshot pixel width." What about treating images on a case-by-case basis, this would mean descriptive CSS class names when inserting images, so for example: "Everyone I've read agrees that screenshots should be PNG and not JPEG." I recommend JPEG for photo-like images, whereas PNG is best for images that contain text that needs to be readable (PNG preserves shape edges to a degree) Cheers, Martin ________________________________ From: Discuss on behalf of M R Sent: Tuesday, 13 February 2018 3:47:28 p.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Martin: That sounds really interesting: I didn't know you could specify by viewport h and w % in CSS (though that's standard in lots of app authoring I've done, for e.g. Windows or Android apps). But then I know next to nothing about modern CSS; I basically got out of client-side web development as such in the early '00s. Mick, what do you think? To *some* degree it seems like going with viewport width (and height) % would address our issues--but then again, perhaps not completely. If I put in a 1300 px wide screenshot and our CSS, revised along the lines Martin suggests, rendered that as (say) 80% of someone's 800-pixel width screen, then the image would all fit in their screen, but the details would be tiny, probably too tiny to be useful. So we might still need some absolute limit on screenshot pixel width. The thing is, there is a whole galactic-sized industry of technical writing out there, still cranking out documentation with screenshots (despite my best efforts to move them toward video ?); so you'd think there would be best-practice guidelines well established around this very question. You would think. But in the google searching I've just done, while I've unearthed some very sensible articles/posts from individuals talking about what makes for better and worse screenshots, I get no sense at all of a widely-accepted standard width or resolution. If those standards are out there, they're embedded in full tech-writing courses and not seemingly accessible to googling. Everyone I've read agrees that screenshots should be PNG and not JPEG. Most people agree that PRNTSCRN is too blunt-force, at least without cropping, not least because it will inevitably capture personal screen details that are idiosyncratic and distracting, and irrelevant. Any tech-writing professional is presumably using some specialized screen capture software that allows for selection of a customized area or a specified app or window (the one I use even tries to pick out specific panes/windows within the software UI I'm demo-ing, which is great when it works). But none of this speaks to how large (and in what resolution) the captured area actually should be. The common-sense answer is: "large enough to show what you need to show, ie what is actually relevant to your demonstration." Mick, that was basically your original answer, and it's truly sound common sense; but then I would go right back to my original response to it. Maybe where that leaves us is the idea that, if the software you're trying to demonstrate really does require you to see, simultaneously, multiple panes of a UI stretching across, say, 1000+ pixels or more, then perhaps we're beyond the limits of the static text-and-screenshot genre of documentation anyway. So maybe we just kick the image-width limit up slightly, to 1000 (though that was a purely arbitrary number); or maybe we change the CSS to a % of viewport, but still establish a defacto max width of 1000 for FM screenshots. Or maybe the de facto standard should remain 800 px. Truly it beats me. I'm going to stay below 800 px for the duration of the Shotcut manual, anyway -- even though I'd be truly surprised if many Shotcut users actually confined themselves to that little real estate in using the tool. Btw, here's some survey data on display sizes and their historical trend, from a pretty established source: https://www.w3schools.com/browsers/browsers_display.asp OTOH, the typical FM manual consumer might be a lot more old-school than the median of these trends. Best, Matt ________________________________ From: Discuss on behalf of Martin Kean Sent: Monday, February 12, 2018 5:37 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi there, I'm a little late to the conversation, but wondering if pixels are the best for width within device screens or for the printed page. I often use vw and vh, viewport width and viewport height: https://css-tricks.com/fun-viewport-units/ and here ... https://css-tricks.com/full-width-containers-limited-width-parents/ ... 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. I'm really getting into CSS Grid: https://css-tricks.com/snippets/css/complete-guide-grid/ http://jensimmons.com/post/feb-27-2017/learn-css-grid ... but this would be too long a stride out at this point, so I suggest viewport widths: img { border-style: none; border: 0; box-sizing: border-box; min-width: 80vw; /* 80% of the screen or page width, or whatever % you prefer */ max-width: 95vw; /* again, whatever % you prefer */ height: auto; } I'd like to work with anyone on this so please keep me in the loop. Thanks, Martin ________________________________ From: Discuss on behalf of M R Sent: Tuesday, 13 February 2018 10:29:46 a.m. To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Mick: 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. 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. 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. 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). best, Matt ________________________________ From: Discuss on behalf of Mick Chesterman Sent: Monday, February 12, 2018 3:16 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Hi Matt, 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. And you make a good case for looking at different situations and using doc tools based on the most appropriate response. As far as the screen limit, at the moment, the css override is the following; img { border-style:none; max-width:800px; height: auto; } 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. This has been helpful for me to start up conversations to get moved to booktype 2 as well. Thanks Mick From: Discuss on behalf of M R Sent: 10 February 2018 21:07 To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images Mick: 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: 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. 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. 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. 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. 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 movingparts 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. 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. Best, Matt ________________________________ From: Discuss on behalf of mick at flossmanuals.net Sent: Saturday, February 10, 2018 5:57 AM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] issues with Kdenlive manual images On 09/02/18 20:16, M R wrote: > 00 px is a pretty draconian limit for modern screenshots, though, as > no one in their right might would use most of these editing tools at > that width. I get that the print version needs some kind of image > width limit. One would think that the "Constrain Proportions" > function would at least, you know, constrain proportions if the image > exceeded that limit, and simply show a smaller overall screenshot. > But I can't get that to work in the editor: it seems to always take > the actual height but constain the width. No doubt why they fixed it > in 2.2... As Rosalind pointed out, I does seem to do that for the published version. But I have seen squished images in the editor too. So maybe we can work on a guideline for images width based on what they look like when they are outputted to pdf. 800px for me seems about right as above that it is hard to see what you want users to look at. For me although the challenge of drawing the attention to the most relevant part of the screen. Thanks Mick _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Discuss Info Page - lists.flossmanuals.net lists.flossmanuals.net 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 ... "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 " -------------- next part -------------- An HTML attachment was scrubbed... URL: From rclord at seaserpent.com Tue Feb 13 13:34:36 2018 From: rclord at seaserpent.com (Rosalind Lord) Date: Tue, 13 Feb 2018 13:34:36 -0800 Subject: [FM Discuss] "Introduction to Video Editing With ShotCut" now has a section for installing Shotcut in the Mac Message-ID: Hi all: Just letting you know that the chapter on installing Shotcut in the book "Introduction to Video Editing With ShotCut? now has a section for installing Shotcut in the Mac. I look forward to any feedback you might have. - Rosalind Check out Sea Serpent Design's cards and gifts ? ... at Zazzle: Ladybug Hearts Card by rclord Dog King and Queen of Hearts by rclord ... at Redbubble: -------------- next part -------------- An HTML attachment was scrubbed... URL: From matrobnew at hotmail.com Tue Feb 13 13:56:09 2018 From: matrobnew at hotmail.com (M R) Date: Tue, 13 Feb 2018 21:56:09 +0000 Subject: [FM Discuss] "Introduction to Video Editing With ShotCut" now has a section for installing Shotcut in the Mac In-Reply-To: References: Message-ID: Rosalind: Many thanks. I just had a look (why not instant gratification? I was just grading papers anyway) and it looks great -- I changed one semi-colon to a comma, cuz I'm an English Professor ?, but that's it. That's a lot of screenshots but it looks like you need them all; it really seems like OS X or whatever you're on makes you jump through a lot of hoops to install new software (I'll bet that's for anything that doesn't come from within the Apple universe). More than Windows 10 even. So esp now that you'd got it installed, I'd love to have you take a look, time permitting, at those next three chapters in 'Getting started', all of which I've finished at least in first-draft form. Not that I expect you'll have played around with Shotcut yourself to this extent yet, but just to see if they make any sense to you (esp if you *haven't* played around much yet). My impression is that every video editor has a somewhat different workflow as far as importing assets and getting them ready to edit; this one clearly made sense to the Shotcut team, and I've tried to make it sensible for the reader. But only some readers can tell me that. However, this is only if/when you have the time; as it is I hugely appreciate your doing the Mac install bit. Now we just need to find a Linux user... Longer term, as I said before, I'm very open to you or other users contributing their own 'how-to' chapters as well (it's highly likely that you have more video-editing experience than I do). But that will require us figuring how which topics I plan to cover and which are up for grabs. My next chapter will prob. be on using Filters to add intro titles and captions, also fade-in and fade-out; and then perhaps one the basics of adding and editing an audio track; but I haven't thought beyond that. Color-enhancement stuff, for example, is entirely beyond me and would be great for the "Taking it Further" section. This is just if you have some particular yen for more technical writing right now. Or later -- this manual will definitely be a work-in-progress for some time. best, Matt ________________________________ From: Discuss on behalf of Rosalind Lord Sent: Tuesday, February 13, 2018 2:34 PM To: discuss at lists.flossmanuals.net Subject: [FM Discuss] "Introduction to Video Editing With ShotCut" now has a section for installing Shotcut in the Mac Hi all: Just letting you know that the chapter on installing Shotcut in the book "Introduction to Video Editing With ShotCut? now has a section for installing Shotcut in the Mac. I look forward to any feedback you might have. - Rosalind Check out Sea Serpent Design's cards and gifts? ... at Zazzle: [Ladybug Hearts Card] Ladybug Hearts Card by rclord [Dog King and Queen of Hearts] Dog King and Queen of Hearts by rclord ... at Redbubble: [Buy my art] -------------- next part -------------- An HTML attachment was scrubbed... URL: From rclord at seaserpent.com Tue Feb 13 15:46:38 2018 From: rclord at seaserpent.com (Rosalind Lord) Date: Tue, 13 Feb 2018 15:46:38 -0800 Subject: [FM Discuss] "Introduction to Video Editing With ShotCut" now has a section for installing Shotcut in the Mac In-Reply-To: References: Message-ID: <93BE13A3-CC30-4035-A6ED-C3218F0FF1AE@seaserpent.com> Hi Matt: Sure, I?d be happy to read the next three Getting Started chapters (I?m pursuing a career in technical writing, so yes I do have a yen for it). Does it have to be done by a certain time? I think you?re probably right about video editors each having workflows. I?ve used some video editors, but not a lot. I?m also interested in contributing how-to chapters if and/or when needed. - Rosalind > On Feb 13, 2018, at 1:56 PM, M R wrote: > > Rosalind: > > Many thanks. I just had a look (why not instant gratification? I was just grading papers anyway) and it looks great -- I changed one semi-colon to a comma, cuz I'm an English Professor ?, but that's it. That's a lot of screenshots but it looks like you need them all; it really seems like OS X or whatever you're on makes you jump through a lot of hoops to install new software (I'll bet that's for anything that doesn't come from within the Apple universe). More than Windows 10 even. > > So esp now that you'd got it installed, I'd love to have you take a look, time permitting, at those next three chapters in 'Getting started', all of which I've finished at least in first-draft form. Not that I expect you'll have played around with Shotcut yourself to this extent yet, but just to see if they make any sense to you (esp if you *haven't* played around much yet). My impression is that every video editor has a somewhat different workflow as far as importing assets and getting them ready to edit; this one clearly made sense to the Shotcut team, and I've tried to make it sensible for the reader. But only some readers can tell me that. However, this is only if/when you have the time; as it is I hugely appreciate your doing the Mac install bit. > > Now we just need to find a Linux user... > > Longer term, as I said before, I'm very open to you or other users contributing their own 'how-to' chapters as well (it's highly likely that you have more video-editing experience than I do). But that will require us figuring how which topics I plan to cover and which are up for grabs. My next chapter will prob. be on using Filters to add intro titles and captions, also fade-in and fade-out; and then perhaps one the basics of adding and editing an audio track; but I haven't thought beyond that. Color-enhancement stuff, for example, is entirely beyond me and would be great for the "Taking it Further" section. This is just if you have some particular yen for more technical writing right now. Or later -- this manual will definitely be a work-in-progress for some time. > > best, > > Matt > > From: Discuss on behalf of Rosalind Lord > Sent: Tuesday, February 13, 2018 2:34 PM > To: discuss at lists.flossmanuals.net > Subject: [FM Discuss] "Introduction to Video Editing With ShotCut" now has a section for installing Shotcut in the Mac > > Hi all: > > Just letting you know that the chapter on installing Shotcut in the book "Introduction to Video Editing With ShotCut? now has a section for installing Shotcut in the Mac. > > I look forward to any feedback you might have. > > - Rosalind > > Check out Sea Serpent Design's cards and gifts ? > > ... at Zazzle: > ? > Ladybug Hearts Card > by rclord > ? > Dog King and Queen of Hearts > by rclord ... at Redbubble: > > > > _______________________________________________ > Discuss mailing list > Discuss at lists.flossmanuals.net > http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Check out Sea Serpent Design's cards and gifts ? ... at Zazzle: Ladybug Hearts Card by rclord Dog King and Queen of Hearts by rclord ... at Redbubble: -------------- next part -------------- An HTML attachment was scrubbed... URL: From matrobnew at hotmail.com Tue Feb 13 15:52:29 2018 From: matrobnew at hotmail.com (M R) Date: Tue, 13 Feb 2018 23:52:29 +0000 Subject: [FM Discuss] "Introduction to Video Editing With ShotCut" now has a section for installing Shotcut in the Mac In-Reply-To: <93BE13A3-CC30-4035-A6ED-C3218F0FF1AE@seaserpent.com> References: , <93BE13A3-CC30-4035-A6ED-C3218F0FF1AE@seaserpent.com> Message-ID: Hi Rosland: That would be great, and no, there's no deadline. Any feedback you could give would be great, whenever you can. The finished chapters might even inspire you to fiddle with the software yourself. And definitely open, yes, on chapter contributions on the more advanced topics, whenever. As I say, this whole manual will be a work-in-progress for some time, maybe indefinitely. As it happens I am also new, or at least newly-returning, to Tech writing, so I've got a certain amount of bandwidth (and motivation) for volunteer projects like this. But that could end abruptly, and the new manual will be wherever it is at that point. matt ________________________________ From: Discuss on behalf of Rosalind Lord Sent: Tuesday, February 13, 2018 4:46 PM To: discuss at lists.flossmanuals.net Subject: Re: [FM Discuss] "Introduction to Video Editing With ShotCut" now has a section for installing Shotcut in the Mac Hi Matt: Sure, I?d be happy to read the next three Getting Started chapters (I?m pursuing a career in technical writing, so yes I do have a yen for it). Does it have to be done by a certain time? I think you?re probably right about video editors each having workflows. I?ve used some video editors, but not a lot. I?m also interested in contributing how-to chapters if and/or when needed. - Rosalind On Feb 13, 2018, at 1:56 PM, M R > wrote: Rosalind: Many thanks. I just had a look (why not instant gratification? I was just grading papers anyway) and it looks great -- I changed one semi-colon to a comma, cuz I'm an English Professor ?, but that's it. That's a lot of screenshots but it looks like you need them all; it really seems like OS X or whatever you're on makes you jump through a lot of hoops to install new software (I'll bet that's for anything that doesn't come from within the Apple universe). More than Windows 10 even. So esp now that you'd got it installed, I'd love to have you take a look, time permitting, at those next three chapters in 'Getting started', all of which I've finished at least in first-draft form. Not that I expect you'll have played around with Shotcut yourself to this extent yet, but just to see if they make any sense to you (esp if you *haven't* played around much yet). My impression is that every video editor has a somewhat different workflow as far as importing assets and getting them ready to edit; this one clearly made sense to the Shotcut team, and I've tried to make it sensible for the reader. But only some readers can tell me that. However, this is only if/when you have the time; as it is I hugely appreciate your doing the Mac install bit. Now we just need to find a Linux user... Longer term, as I said before, I'm very open to you or other users contributing their own 'how-to' chapters as well (it's highly likely that you have more video-editing experience than I do). But that will require us figuring how which topics I plan to cover and which are up for grabs. My next chapter will prob. be on using Filters to add intro titles and captions, also fade-in and fade-out; and then perhaps one the basics of adding and editing an audio track; but I haven't thought beyond that. Color-enhancement stuff, for example, is entirely beyond me and would be great for the "Taking it Further" section. This is just if you have some particular yen for more technical writing right now. Or later -- this manual will definitely be a work-in-progress for some time. best, Matt ________________________________ From: Discuss > on behalf of Rosalind Lord > Sent: Tuesday, February 13, 2018 2:34 PM To: discuss at lists.flossmanuals.net Subject: [FM Discuss] "Introduction to Video Editing With ShotCut" now has a section for installing Shotcut in the Mac Hi all: Just letting you know that the chapter on installing Shotcut in the book "Introduction to Video Editing With ShotCut? now has a section for installing Shotcut in the Mac. I look forward to any feedback you might have. - Rosalind Check out Sea Serpent Design's cards and gifts? ... at Zazzle: [Ladybug Hearts Card] Ladybug Hearts Card by rclord [Dog King and Queen of Hearts] Dog King and Queen of Hearts by rclord ... at Redbubble: [Buy my art] _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Check out Sea Serpent Design's cards and gifts? ... at Zazzle: [Ladybug Hearts Card] Ladybug Hearts Card by rclord [Dog King and Queen of Hearts] Dog King and Queen of Hearts by rclord ... at Redbubble: [Buy my art] -------------- next part -------------- An HTML attachment was scrubbed... URL: From mick at flossmanuals.net Wed Feb 14 04:44:15 2018 From: mick at flossmanuals.net (mick at flossmanuals.net) Date: Wed, 14 Feb 2018 12:44:15 +0000 Subject: [FM Discuss] issues with Kdenlive manual images In-Reply-To: References: <8612cc38-b6c5-ffdf-2cf8-74301b26b341@flossmanuals.net> <1518430572076.2439@mmu.ac.uk> Message-ID: Hi there, No there isn't a storage place so yes I think it's good to have a folder in this repo https://gitlab.com/flossmanuals/fm_booktype Martin you have access via the admin login to make those changes here http://write.flossmanuals.net/_control/settings/appearance/ Matt, these are global settings and there's no fine tuning available for books. I do think this is a positive discussion as while the web -> print ethos was what FM was founded on and really drove the development and take up of the FM via Book Sprints where a printed book was the pot of gold at the end of the rainbow, realistically now most I would say over 90% people will read FM docs via the web, and via searches. nice one Mick On 13/02/18 06:41, Martin Kean wrote: > Mick is there a place on the server to store global CSS stylesheets? > If so, then could we have a GitLab repo, and link to (in the meantime) > the stylesheets from Objavi > using @import url("full-width-images-global-styles.css"); for example? > > Matt, ''gracefully" is not an actual CSS word, I've just used it here > as a class name. > > Working example here: https://martinkean.com/img-test.html > > ; Martin > ------------------------------------------------------------------------ > *From:* Discuss on behalf of > M R > *Sent:* Tuesday, 13 February 2018 6:20:07 p.m. > *To:* discuss at lists.flossmanuals.net > *Subject:* Re: [FM Discuss] issues with Kdenlive manual images > > > well, it looks gorgeous -- I was thinking I could do that in js, but > CSS has clearly come a long way. > > > I guess the question is how much freedom we have to manipulate the CSS > at FM, either globally or (especially) case-by-case. Would your > solution work as a global? > > > I love, in any case, that ''gracefully" is an actual word in CSS now... > > > matt > > > > ------------------------------------------------------------------------ > *From:* Discuss on behalf of > Martin Kean > *Sent:* Monday, February 12, 2018 9:22 PM > *To:* discuss at lists.flossmanuals.net > *Subject:* Re: [FM Discuss] issues with Kdenlive manual images > > > Hi Matt, > > > Yup, so, > > > "if I felt I truly needed something like a 1400 px screenshot, I could > specify, say, 130% viewport width," > > > Here, in the example below, the image gracefully scales to the > viewport width, but when the width narrows to less than 460px, the > minimum width becomes twice the width of the viewport (200vw) > > > CSS: > > img { > display: block; > } > > .fullest-width { > box-sizing: border-box; > margin: 0; > width: 100vw; > height: auto; > } > > .gracefully { > -webkit-transition: all 0.3s ease-out; > transition: all 0.3s ease-out; > } > > @media screen and (max-width: 460px) { > .fullest-width { > min-width: 200vw; > overflow: visible; > } > } > > > HTML: > >
> >
> > Does that work? > Cheers, Martin > ------------------------------------------------------------------------ > *From:* Discuss on behalf of > M R > *Sent:* Tuesday, 13 February 2018 4:16:14 p.m. > *To:* discuss at lists.flossmanuals.net > *Subject:* Re: [FM Discuss] issues with Kdenlive manual images > > > Martin: > > > So, to be clear, taking your idea of case-by-case: if I felt I > truly needed something like a 1400 px screenshot, I could specify, > say, 130% viewport width, rather than the standard 80%, and then > people with smaller screens would just get a scrollbar? But...if you > are working with viewport w and h %, is that a maximum for IF your > browser can't accept the full image in it's original size? Or does it > instead establish a fixed %, regardless of window size? Because I'd > hate to enforce a massive screenshot image, and a scrollbar, for > people who already have large enough windows to accommodate the > full image size (which I remain convinced would be the majority). > > > I'm thinking we may need something like <100% viewport width, > specified globally in CSS, in conjunction with some kind of de facto > px limit for screenshots. Though I may just not be understanding your > proposal. > > > Matt > > > > ------------------------------------------------------------------------ > *From:* Discuss on behalf of > Martin Kean > *Sent:* Monday, February 12, 2018 7:58 PM > *To:* discuss at lists.flossmanuals.net > *Subject:* Re: [FM Discuss] issues with Kdenlive manual images > > Hi Matt, > > "... it seems like going with viewport width (and height) % would > address our issues--but then again, perhaps not completely. If I put > in a 1300 px wide screenshot and our CSS, revised along the lines > Martin suggests, rendered that as (say) 80% of someone's 800-pixel > width screen, then the image would all fit in their screen, but the > details would be tiny, probably too tiny to be useful. So we might > still need some absolute limit on screenshot pixel width." > > What about treating images on a case-by-case basis, this would mean > descriptive CSS class names when inserting images, so for example: > > > > > > > "Everyone I've read agrees that screenshots should be PNG and not JPEG." > > I recommend JPEG for photo-like images, whereas PNG is best for images > that contain text that needs to be readable (PNG preserves shape edges > to a degree) > > Cheers, Martin > ------------------------------------------------------------------------ > *From:* Discuss on behalf of > M R > *Sent:* Tuesday, 13 February 2018 3:47:28 p.m. > *To:* discuss at lists.flossmanuals.net > *Subject:* Re: [FM Discuss] issues with Kdenlive manual images > > > Martin: > > > That sounds really interesting: I didn't know you could specify by > viewport h and w % in CSS (though that's standard in lots of app > authoring I've done, for e.g. Windows or Android apps). But then I > know next to nothing about modern CSS; I basically got out of > client-side web development as such in the early '00s. > > > Mick, what do you think? To *some* degree it seems like going with > viewport width (and height) % would address our issues--but then > again, perhaps not completely. If I put in a 1300 px wide screenshot > and our CSS, revised along the lines Martin suggests, rendered that as > (say) 80% of someone's 800-pixel width screen, then the image would > all fit in their screen, but the details would be tiny, probably too > tiny to be useful. So we might still need some absolute limit on > screenshot pixel width. > > > The thing is, there is a whole galactic-sized industry of technical > writing out there, still cranking out documentation with screenshots > (despite my best efforts to move them toward video ?); so you'd think > there would be best-practice guidelines well established around this > very question. You would think. But in the google searching I've > just done, while I've unearthed some very sensible articles/posts from > individuals talking about what makes for better and worse screenshots, > I get no sense at all of a widely-accepted standard width or > resolution. If those standards are out there, they're embedded in > full tech-writing courses and not seemingly accessible to googling. > > > Everyone I've read agrees that screenshots should be PNG and not > JPEG. Most people agree that PRNTSCRN is too blunt-force, at least > without cropping, not least because it will inevitably capture > personal screen details that are idiosyncratic and distracting, and > irrelevant. Any tech-writing professional is presumably using some > specialized screen capture software that allows for selection of a > customized area or a specified app or window (the one I use even tries > to pick out specific panes/windows within the software UI I'm > demo-ing, which is great when it works). But none of this speaks to > how large (and in what resolution) the captured area actually should be. > > > The common-sense answer is: "large enough to show what you need to > show, ie what is actually relevant to your demonstration." Mick, that > was basically your original answer, and it's truly sound common sense; > but then I would go right back to my original response to it. Maybe > where that leaves us is the idea that, if the software you're trying > to demonstrate really does require you to see, simultaneously, > multiple panes of a UI stretching across, say, 1000+ pixels or more, > then perhaps we're beyond the limits of the static text-and-screenshot > genre of documentation anyway. So maybe we just kick the image-width > limit up slightly, to 1000 (though that was a purely arbitrary > number); or maybe we change the CSS to a % of viewport, but still > establish a defacto max width of 1000 for FM screenshots. Or maybe > the de facto standard should remain 800 px. Truly it beats me. > > > I'm going to stay below 800 px for the duration of the Shotcut manual, > anyway -- even though I'd be truly surprised if many Shotcut users > actually confined themselves to that little real estate in using the > tool. Btw, here's some survey data on display sizes and their > historical trend, from a pretty established source: > > > https://www.w3schools.com/browsers/browsers_display.asp > > > OTOH, the typical FM manual consumer might be a lot more old-school > than the median of these trends. > > > Best, > > > Matt > > ------------------------------------------------------------------------ > *From:* Discuss on behalf of > Martin Kean > *Sent:* Monday, February 12, 2018 5:37 PM > *To:* discuss at lists.flossmanuals.net > *Subject:* Re: [FM Discuss] issues with Kdenlive manual images > > > Hi there, > > > I'm a little late to the conversation, but wondering if pixels are the > best for width within device screens or for the printed page. > > I often use vw and vh, viewport width and viewport height: > > > https://css-tricks.com/fun-viewport-units/ > > > and here ... > > > https://css-tricks.com/full-width-containers-limited-width-parents/ > > > ... 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. > > I'm really getting into CSS Grid: > > > https://css-tricks.com/snippets/css/complete-guide-grid/ > > http://jensimmons.com/post/feb-27-2017/learn-css-grid > > > ... but this would be too long a stride out at this point, so I > suggest viewport widths: > > > img { > border-style: none; > border: 0; > box-sizing: border-box; > min-width: 80vw; /* 80% of the screen or page width, or > whatever % you prefer */ > max-width: 95vw; /* again, whatever % you prefer */ > height: auto; > } > > I'd like to work with anyone on this so please keep me in the loop. > > > Thanks, Martin > > ------------------------------------------------------------------------ > *From:* Discuss on behalf of > M R > *Sent:* Tuesday, 13 February 2018 10:29:46 a.m. > *To:* discuss at lists.flossmanuals.net > *Subject:* Re: [FM Discuss] issues with Kdenlive manual images > > > Hi Mick: > > > 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. > > > 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. > > > 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. > > > 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). > > > best, > > > Matt > > > > ------------------------------------------------------------------------ > *From:* Discuss on behalf of > Mick Chesterman > *Sent:* Monday, February 12, 2018 3:16 AM > *To:* discuss at lists.flossmanuals.net > *Subject:* Re: [FM Discuss] issues with Kdenlive manual images > > > Hi Matt, > > > 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. > > And you make a good case for looking at different situations and using > doc tools based on the most appropriate response. > > > As far as the screen limit, at the moment, the css override is the > following; > > img { > border-style:none; > max-width:800px; > height: auto; > } > > > 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. > > > This has been helpful for me to start up conversations to get moved to > booktype 2 as well. > > > Thanks > > Mick > > > > > > > *From:* Discuss on behalf of > M R > > *Sent:* 10 February 2018 21:07 > *To:* discuss at lists.flossmanuals.net > *Subject:* Re: [FM Discuss] issues with Kdenlive manual images > > > Mick: > > > 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: > > > 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. > > > 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. > > > 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. > > > 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. > > > 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 /moving/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. > > > 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. > > > Best, > > > Matt > > > > > > ------------------------------------------------------------------------ > *From:* Discuss on behalf of > mick at flossmanuals.net > *Sent:* Saturday, February 10, 2018 5:57 AM > *To:* discuss at lists.flossmanuals.net > *Subject:* Re: [FM Discuss] issues with Kdenlive manual images > > > > On 09/02/18 20:16, M R wrote: > > 00 px is a pretty draconian limit for modern screenshots, though, as > > no one in their right might would use most of these editing tools at > > that width. I get that the print version needs some kind of image > > width limit. One would think that the "Constrain Proportions" > > function would at least, you know, constrain proportions if the image > > exceeded that limit, and simply show a smaller overall screenshot. > > But I can't get that to work in the editor: it seems to always take > > the actual height but constain the width. No doubt why they fixed it > > in 2.2... > > As Rosalind pointed out, I does seem to do that for the published > version. But I have seen squished images in the editor too. > > So maybe we can work on a guideline for images width based on what they > look like when they are outputted to pdf. 800px for me seems about right > as above that it is hard to see what you want users to look at. > > For me although the challenge of drawing the attention to the most > relevant part of the screen. > > Thanks > Mick > _______________________________________________ > Discuss mailing list > Discuss at lists.flossmanuals.net > http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - > you can unsubscribe here > Discuss Info Page - lists.flossmanuals.net > > lists.flossmanuals.net > 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 ... > > > > "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 " > > > _______________________________________________ > Discuss mailing list > Discuss at lists.flossmanuals.net > http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here -------------- next part -------------- An HTML attachment was scrubbed... URL: From gpittman at iglou.com Thu Feb 15 10:23:20 2018 From: gpittman at iglou.com (Gregory Pittman) Date: Thu, 15 Feb 2018 13:23:20 -0500 Subject: [FM Discuss] some questions about booki Message-ID: <636ec736-9f97-8a45-0956-4cf9853aa6c2@iglou.com> I've started a new book, Python Scripting with Scribus, and probably am beginning to see the light at the end of the writing tunnel. I know it's been mentioned that you can use CSS for books, but I'm unclear where to plug this in. Is there a way to create a style sheet, or do I just put some style tags in the HTML? Also, for the cover. There are various formats possible, but it says to size the file appropriately -- what's that? There isn't any mention of dimensions or proportions. I uploaded a PDF cover (based on US Letter size), but there didn't seem to be any way to get a view of how it would look as the cover. Greg From matrobnew at hotmail.com Thu Feb 15 18:43:24 2018 From: matrobnew at hotmail.com (M R) Date: Fri, 16 Feb 2018 02:43:24 +0000 Subject: [FM Discuss] some questions about booki In-Reply-To: <636ec736-9f97-8a45-0956-4cf9853aa6c2@iglou.com> References: <636ec736-9f97-8a45-0956-4cf9853aa6c2@iglou.com> Message-ID: Hi All: Greg, just based on the last few weeks' discussion, it seems like the answer to your CSS question is that CSS has to be set globally (ie for all pages in all books on the FM platform); and that more granular formatting choices need to be done via the tools within Booktype itself for individual pages/chapters. However, your other question on the cover graphics is exactly the same as I had, re the new Shotcut manual cover art. Hopefully Mick can answer that. Matt ________________________________ From: Discuss on behalf of Gregory Pittman Sent: Thursday, February 15, 2018 11:23 AM To: FM Discuss Subject: [FM Discuss] some questions about booki I've started a new book, Python Scripting with Scribus, and probably am beginning to see the light at the end of the writing tunnel. I know it's been mentioned that you can use CSS for books, but I'm unclear where to plug this in. Is there a way to create a style sheet, or do I just put some style tags in the HTML? Also, for the cover. There are various formats possible, but it says to size the file appropriately -- what's that? There isn't any mention of dimensions or proportions. I uploaded a PDF cover (based on US Letter size), but there didn't seem to be any way to get a view of how it would look as the cover. Greg _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Discuss Info Page - lists.flossmanuals.net lists.flossmanuals.net 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 ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From gpittman at iglou.com Fri Feb 16 06:23:39 2018 From: gpittman at iglou.com (Gregory Pittman) Date: Fri, 16 Feb 2018 09:23:39 -0500 Subject: [FM Discuss] some questions about booki In-Reply-To: References: <636ec736-9f97-8a45-0956-4cf9853aa6c2@iglou.com> Message-ID: <7f7b13e5-4b42-d2b3-eb91-7b4fa213916d@iglou.com> On 02/15/2018 09:43 PM, M R wrote: > Hi All: > > > Greg, just based on the last few weeks' discussion, it seems like the > answer to your CSS question is that CSS has to be set globally (ie for > all pages in all books on the FM platform); and that more > granular?formatting choices need to be done via the tools within > Booktype itself for individual pages/chapters.?? > So, in other words, I should be able to override CSS with style tags in the html of the book... Greg From mick at flossmanuals.net Fri Feb 16 06:35:56 2018 From: mick at flossmanuals.net (mick at flossmanuals.net) Date: Fri, 16 Feb 2018 14:35:56 +0000 Subject: [FM Discuss] some questions about booki In-Reply-To: <7f7b13e5-4b42-d2b3-eb91-7b4fa213916d@iglou.com> References: <636ec736-9f97-8a45-0956-4cf9853aa6c2@iglou.com> <7f7b13e5-4b42-d2b3-eb91-7b4fa213916d@iglou.com> Message-ID: <55b8d552-636f-4264-404f-e5e10e3c924e@flossmanuals.net> Let's give it a go! I am worried an html tidier might strip out classes but not sure if that's true On 16/02/18 14:23, Gregory Pittman wrote: > On 02/15/2018 09:43 PM, M R wrote: >> Hi All: >> >> >> Greg, just based on the last few weeks' discussion, it seems like the >> answer to your CSS question is that CSS has to be set globally (ie for >> all pages in all books on the FM platform); and that more >> granular formatting choices need to be done via the tools within >> Booktype itself for individual pages/chapters. >> > So, in other words, I should be able to override CSS with style tags in > the html of the book... > > Greg > > _______________________________________________ > Discuss mailing list > Discuss at lists.flossmanuals.net > http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here From mario.buoninfante at gmail.com Tue Feb 27 14:32:16 2018 From: mario.buoninfante at gmail.com (mario buoninfante) Date: Tue, 27 Feb 2018 22:32:16 +0000 Subject: [FM Discuss] ChucK manual Message-ID: Hi everyone, is there anyone interested in updating the ChucK programming language manual? I'm checking it now and looking for a little help. give me a shout in case you interested. cheers, Mario From mario.buoninfante at gmail.com Tue Feb 27 14:34:27 2018 From: mario.buoninfante at gmail.com (mario buoninfante) Date: Tue, 27 Feb 2018 22:34:27 +0000 Subject: [FM Discuss] deleting a paragraph Message-ID: <9f8f4fba-7beb-e151-42d5-5f0014996552@gmail.com> Hi everyone, sorry for the silly question, I'm a newbie. how do I delete a paragraph? I'm asking cause I'm working on the ChucK manual, and there's a duplicate that seems to cause problems, so I'd like to get rid of it. cheers, Mario From matrobnew at hotmail.com Tue Feb 27 15:29:13 2018 From: matrobnew at hotmail.com (M R) Date: Tue, 27 Feb 2018 23:29:13 +0000 Subject: [FM Discuss] deleting a paragraph In-Reply-To: <9f8f4fba-7beb-e151-42d5-5f0014996552@gmail.com> References: <9f8f4fba-7beb-e151-42d5-5f0014996552@gmail.com> Message-ID: Mario: Do you just mean a paragraph of text (and/or images) within an existing chapter? In that case I think you'd just delete it through the editor the same way you would in any word processor. Maybe I don't understand the question. For deleting entire chapters, the only way I've found (though there might be others) is to go to the table-of-contents view and drag that chapter out of the active book structure down to the area below. But I doubt you're asking that. Matt ________________________________ From: Discuss on behalf of mario buoninfante Sent: Tuesday, February 27, 2018 4:34 PM To: discuss at lists.flossmanuals.net Subject: [FM Discuss] deleting a paragraph Hi everyone, sorry for the silly question, I'm a newbie. how do I delete a paragraph? I'm asking cause I'm working on the ChucK manual, and there's a duplicate that seems to cause problems, so I'd like to get rid of it. cheers, Mario _______________________________________________ Discuss mailing list Discuss at lists.flossmanuals.net http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here Discuss Info Page - lists.flossmanuals.net lists.flossmanuals.net 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 ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.Chesterman at mmu.ac.uk Wed Feb 28 01:28:32 2018 From: M.Chesterman at mmu.ac.uk (Mick Chesterman) Date: Wed, 28 Feb 2018 09:28:32 +0000 Subject: [FM Discuss] deleting a paragraph In-Reply-To: <9f8f4fba-7beb-e151-42d5-5f0014996552@gmail.com> References: <9f8f4fba-7beb-e151-42d5-5f0014996552@gmail.com> Message-ID: Hi Mario, Great idea to update the Chuck Manual. I'll be happy to help you navigate the system. I can see the problem you are talking about. It's a duplicate chapter name causing problems. I think this is fixable but I have a proposal. If you were open to the idea I think we can use Chuck as a way of testing a new updated writing system we have been invited to test by Booktype ( who provide the writing platform for FM) It's here. If you and anyone else is up for testing it please create an account and let me know. https://omnibook.pro/ Thanks Mick > -----Original Message----- > From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of > mario buoninfante > Sent: 27 February 2018 22:34 > To: discuss at lists.flossmanuals.net > Subject: [FM Discuss] deleting a paragraph > > Hi everyone, > > > sorry for the silly question, I'm a newbie. how do I delete a paragraph? > I'm asking cause I'm working on the ChucK manual, and there's a duplicate that > seems to cause problems, so I'd like to get rid of it. > > > cheers, > > Mario > > _______________________________________________ > Discuss mailing list > Discuss at lists.flossmanuals.net > http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can > unsubscribe here "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 " From mick at flossmanuals.net Wed Feb 28 01:32:44 2018 From: mick at flossmanuals.net (Mick Chesterman) Date: Wed, 28 Feb 2018 09:32:44 +0000 Subject: [FM Discuss] Fwd: Booktype interface translations In-Reply-To: <019631af-cbbc-8cfa-6f9f-96459cedbc73@booktype.org> References: <019631af-cbbc-8cfa-6f9f-96459cedbc73@booktype.org> Message-ID: <62d5d4f7-6988-4cea-3422-f2db19469a01@flossmanuals.net> Hi there, I had a great meeting with Julian and Daniel from Booktype (now a separate company from Sourcefabric) They are keen to keep supporting FLOSS Manuals, and I said we would do our best to help them via community involvement as well. Have a look at the request below about translations and please do get in touch with me or Daniel if you can help. Thanks Mick -------- Forwarded Message -------- Subject: Booktype interface translations Date: Mon, 26 Feb 2018 16:04:22 +0000 From: Daniel James Organisation: Booktype GmbH To: Mick Clearerchannel CC: Julian Sorge | Booktype GmbH Hi Mick, Just thought I'd mention that we now have a lot more interface translations: https://www.transifex.com/sourcefabric/booktype/dashboard/ We would benefit from help with French and also reviews of Spanish, Italian and Portuguese, if you have community members speaking those languages. To get started, any volunteers should create accounts on Transifex at https://www.transifex.com/signup/ then request to join the Booktype project at the link above. Cheers! Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.Chesterman at mmu.ac.uk Wed Feb 28 01:53:59 2018 From: M.Chesterman at mmu.ac.uk (Mick Chesterman) Date: Wed, 28 Feb 2018 09:53:59 +0000 Subject: [FM Discuss] deleting a paragraph In-Reply-To: <9f8f4fba-7beb-e151-42d5-5f0014996552@gmail.com> References: <9f8f4fba-7beb-e151-42d5-5f0014996552@gmail.com> Message-ID: <7a535ff2a2c3480db7c3bf69a410399c@BFEX02.ad.mmu.ac.uk> Hi Mario, In the mean time I've fixed the duplicate chapter problem and created a work in progress manual for you edit here. http://write.flossmanuals.net/chuck-update/_edit/ thx Mick > -----Original Message----- > From: Discuss [mailto:discuss-bounces at lists.flossmanuals.net] On Behalf Of > mario buoninfante > Sent: 27 February 2018 22:34 > To: discuss at lists.flossmanuals.net > Subject: [FM Discuss] deleting a paragraph > > Hi everyone, > > > sorry for the silly question, I'm a newbie. how do I delete a paragraph? > I'm asking cause I'm working on the ChucK manual, and there's a duplicate that > seems to cause problems, so I'd like to get rid of it. > > > cheers, > > Mario > > _______________________________________________ > Discuss mailing list > Discuss at lists.flossmanuals.net > http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can > unsubscribe here "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 " From mario.buoninfante at gmail.com Wed Feb 28 14:25:04 2018 From: mario.buoninfante at gmail.com (mario buoninfante) Date: Wed, 28 Feb 2018 22:25:04 +0000 Subject: [FM Discuss] deleting a paragraph Message-ID: <604431d6-5445-c372-da54-0443d8da841e@gmail.com> Hi Mick, thanks for sorting that out, yap it was matter of duplicate chapters. btw I'd be interested in trying out a new writing system and I created an account on the website you wrote. could give me some info more about it? cheers, Mario