Thread: [Audacity-devel] Provide 'Unrecognised Audio File Format' dialog with help-link button
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Gale A. <ga...@au...> - 2007-08-22 06:18:00
|
Hi We have marked as "essential - done" to "provide 'Unrecognised Audio File Format' dialog with help-link button for more detail. Jimmy Johnson's patch now applied [Done]" But I have just tried (5 August build, so after James checked in the patch) to import a WMA file and I get the file imported and displayed as a fraction of a second and it makes the usual squeak. Have I got to get another build to see this? [Windows] Gale Outbound message virus free. Tested on: 8/22/2007 7:18:00 AM |
From: James C. <cr...@in...> - 2007-08-22 09:30:42
|
Umm... - The description of the 'done-item' is about the help link button which is what Jimmy Johnson's patch provides. - The description of the problem seen is about WMA coming in as a squeak. Two different items. Is what you are looking for automatic detection that a raw file that has been imported does not look like a valid sound? Is it to then get that to then pop up some help to explain what the problem could be? Sure that would be nice, but it is beyond what was planned. Or are you suggesting something simpler? --James Gale Andrews wrote: > Hi > We have marked as "essential - done" to "provide 'Unrecognised Audio File > Format' dialog with help-link button for more detail. Jimmy Johnson's patch now > applied [Done]" > But I have just tried (5 August build, so after James checked in the patch) to > import a WMA file and I get the file imported and displayed as a fraction of a > second and it makes the usual squeak. Have I got to get another build to see > this? [Windows] > Gale |
From: James C. <cr...@in...> - 2007-08-22 14:05:51
|
James Crook wrote: > Umm... > - The description of the 'done-item' is about the help link button which > is what Jimmy Johnson's patch provides. > - The description of the problem seen is about WMA coming in as a squeak. > Two different items. > Is what you are looking for automatic detection that a raw file that has > been imported does not look like a valid sound? Is it to then get that > to then pop up some help to explain what the problem could be? Sure > that would be nice, but it is beyond what was planned. Or are you > suggesting something simpler? > --James OK. A clarification. Open and import can think they have been successful after opening complete rubbish. I've had them open a word document file "ToDo.doc" and treat it as valid sound. In that case the dialog does _not_ appear. The code does: Open based on extension. Else open by trying each importer, and if one _seems_ OK use it Else try to get a better error message by looking at the extension. I propose to change this order to: Open based on extension. Else if the extension suggests we can't open it, then get a good error message. Else open by trying each importer, and if one seems OK use it and set a warning flag At the moment, if we have a SomeTune.mp3 misnamed as SomeTune.wma, then Audacity will successfully open it. With the proposed change, we'll report a problem as .wma files can't be opened. We'll still quite happily open ToDo.doc. That's why I added the warning flag. When it's set we can warn the user that their audio may be bogus because we had to guess what format it was in. Gale - I think this is the best resolution we can do at this stage, short of writing a smart function to tell if audio 'looks' bogus or not. If you agree, I'll make these changes which should be quite simple to do. --James. > Gale Andrews wrote: >> Hi > >> We have marked as "essential - done" to "provide 'Unrecognised Audio File >> Format' dialog with help-link button for more detail. Jimmy Johnson's patch now >> applied [Done]" > >> But I have just tried (5 August build, so after James checked in the patch) to >> import a WMA file and I get the file imported and displayed as a fraction of a >> second and it makes the usual squeak. Have I got to get another build to see >> this? [Windows] > >> Gale |
From: Gale A. <ga...@au...> - 2007-08-23 06:53:24
|
| From James Crook <cr...@in...> | Wed, 22 Aug 2007 15:07:44 +0100 | Subject: [Audacity-devel] Provide 'Unrecognised Audio File Format' | dialog with help-link button | James Crook wrote: | > Umm... | > - The description of the 'done-item' is about the help link button which | > is what Jimmy Johnson's patch provides. | > - The description of the problem seen is about WMA coming in as a squeak. | > Two different items. | > Is what you are looking for automatic detection that a raw file that has | > been imported does not look like a valid sound? Is it to then get that | > to then pop up some help to explain what the problem could be? Sure | > that would be nice, but it is beyond what was planned. Or are you | > suggesting something simpler? | OK. A clarification. Open and import can think they have been | successful after opening complete rubbish. I've had them open a word | document file "ToDo.doc" and treat it as valid sound. In that case the | dialog does _not_ appear. | | The code does: | Open based on extension. | Else open by trying each importer, and if one _seems_ OK use it | Else try to get a better error message by looking at the extension. | | I propose to change this order to: | Open based on extension. | Else if the extension suggests we can't open it, then get a good | error message. | Else open by trying each importer, and if one seems OK use it | and set a warning flag | | At the moment, if we have a SomeTune.mp3 misnamed as SomeTune.wma, | then Audacity will successfully open it. With the proposed change, | we'll report a problem as .wma files can't be opened. We'll still quite | happily open ToDo.doc. That's why I added the warning flag. When it's | set we can warn the user that their audio may be bogus because we had to | guess what format it was in. | | Gale - I think this is the best resolution we can do at this stage, | short of writing a smart function to tell if audio 'looks' bogus or not. | If you agree, I'll make these changes which should be quite simple to do. I assume you did make these changes to CVS shortly afterwards i.e. "Check for unsupported extensions before trying to open file of unknown type"? What my main concern amounts to is the old (mainly Windows) bugbear that if you import valid WMAs and MP4s/M4Ps Audacity treats these as valid files though it can do nothing with them. I know there is a counter-argument that this allows it to import files with these extensions that are actually WAVs or MP3s but this seems to me much a much smaller benefit than the disbenefit of Audacity trying to import perfectly valid files in formats it does not happen to support. So what you propose seems like an improvement to me. I know when I confirmed to Markus a while ago that WMA and QT audio were still importing as squeaks (though he thought he had fixed this in some way) he said he would try to look at it again. Longer term, some detection function like you mention so that Audacity lets through WMAs that are MP3s and blocks valid WMAs would be fine (though longer term we are still hoping aren't we to allow WMA imports one way or another, either for all OS'es with a plug-in importer, or by using MS codecs on Windows systems)? And yes ideally where a file is detected (based on something smarter than looking at the extension) that Audacity can't open, throw a sensible message. Whatever that message is, it should certainly include a clickable link like in Jimmy's patch. With the changes you've made now, I was not quite clear in the case where it's a WMA or MP4 etc. (according to the extension): do I assume the problem report is not Jimmy's dialogue but something not yet written? Also is it possible to modify your idea something like this so as not to lose the slight benefit of opening valid files with incorrect extensions: > Open based on extension. > Else if the extension suggests we can't open it, then get a good error message. >> If user accepts a prompt, then: open by trying each importer, and if one seems OK use it and set a warning flag > Else no further action I may be missing something but I am not sure why in the above proposal "Open based on extension" should think that it can or should open .doc, whereas it correctly thinks from the extension that it can't open WMA. While on about formats I'd like to raise again (not as an essential) the issue that Audacity seems to have great difficulty opening compressed files inside WAV containers such as are commonly saved by portable recorders. This is a common user irritation when these appear to the user to be WAVs, especially as most media players even Windows Media Player can play them. Typically if you try to import these into Audacity it brings up the "unrecognised" flag i.e. Jimmy's dialogue now, but Import Raw is not successful in opening these sort of WAV files. If anyone wants to look at an example (it seems to contain IMA ADPCM data) please go here: http://www.gaclrecords.org.uk/audacitytestfiles.html and grab the "IMA ADPCM WAV". Thanks, James Gale Outbound message virus free. Tested on: 8/23/2007 7:53:24 AM |
From: James C. <cr...@in...> - 2007-08-23 08:45:03
|
Gale Andrews wrote: > I assume you did make these changes to CVS shortly afterwards i.e. > "Check for unsupported extensions before trying to open file of unknown type"? Yes. > With the changes you've made now, I was not quite clear in the case where it's > a WMA or MP4 etc. (according to the extension): do I assume the problem report > is not Jimmy's dialogue but something not yet written? The code actually already included messages for specifically-not-recognised audio formats like wma. These messages were not been used in the case where (e.g.) a wma looked like it could be read by an mp3 importer. Changing the order meant that these messages are now seen. All messages are reported on the error dialog, which now has Jimmy's help button. Uhh... Jimmy's extra button is wma specific... We really want the page it goes to to be a general one about what formats we do and do not recognise... and the url name should reflect that too. There's also a question in my mind about users who are not connected to the internet at that time... but it is better than not having it at all. > Also is it possible to modify your idea something like this so as not to lose the > slight benefit of opening valid files with incorrect extensions: >> Open based on extension. >> Else if the extension suggests we can't open it, then get a good > error message. >>> If user accepts a prompt, then: > open by trying each importer, and if one seems OK use it > and set a warning flag >> Else no further action What we have is I think better. With the prompt you could easily say 'yes please' and then find that none of the importers actually can read it. So what Audacity does now is do the import, set the warning flag, and then tell you that your import may be bogus, and if it is that you want to rename the file to have the correct extension before opening. > I may be missing something but I am not sure why in the above proposal > "Open based on extension" should think that it can or should open .doc, > whereas it correctly thinks from the extension that it can't open WMA. Wma is in a specific exclusion list. .doc isn't. > While on about formats I'd like to raise again (not as an essential) the issue > that Audacity seems to have great difficulty opening compressed files inside > WAV containers such as are commonly saved by portable recorders. This is > a common user irritation when these appear to the user to be WAVs, especially > as most media players even Windows Media Player can play them. Typically > if you try to import these into Audacity it brings up the "unrecognised" flag > i.e. Jimmy's dialogue now, but Import Raw is not successful in opening these > sort of WAV files. If anyone wants to look at an example (it seems to contain > IMA ADPCM data) please go here: > http://www.gaclrecords.org.uk/audacitytestfiles.html Not for the release checklist page, but not one to lose track of either. As a first step, is it appropriate to make a FAQ entry about it? --James. |
From: Gale A. <ga...@au...> - 2007-08-24 07:35:32
|
| From James Crook <cr...@in...> | Thu, 23 Aug 2007 09:46:55 +0100 | Subject: [Audacity-devel] Provide 'Unrecognised Audio File Format' | dialog with help-link button | Uhh... Jimmy's extra button is wma specific... We really want the page | it goes to to be a general one about what formats we do and do not | recognise... and the url name should reflect that too. Sorry I am not with you. The "Error importing" dialogue thrown seems specific to the format attempted where it's on the exclusion list e.g. WMA, M4A, and the URL goes to: http://audacity.sourceforge.net/help/faq?s=files&i=wma-proprietary which despite the title covers all proprietary formats with suggested conversion solutions. | There's also a | question in my mind about users who are not connected to the internet at | that time... I completely agree but if we move to having no inbuilt help in 1.4.0 as has been suggested, this problem will get worse. From what I understand a lot of folks out "in the sticks" in USA are still on dial-up? The salient content of the webpage above is 3 paragraphs - is it too much for a program popup? | > Also is it possible to modify your idea something like this so as not to | > lose the slight benefit of opening valid files with incorrect extensions: | | >> Open based on extension. | >> Else if the extension suggests we can't open it, then get a good | > error message. | >>> If user accepts a prompt, then: | > open by trying each importer, and if one seems OK use it | > and set a warning flag | >> Else no further action | | What we have is I think better. With the prompt you could easily say | 'yes please' and then find that none of the importers actually can read | it. So what Audacity does now is do the import, set the warning flag, | and then tell you that your import may be bogus, and if it is that you | want to rename the file to have the correct extension before opening. What I had in mind was e.g. opening an MP3 named as a WMA or M4A (this was the former justification given for importing WMAs and M4As as -usually- noise). Audacity will now not attempt to import either WMA or M4A ; you are just told it is an WMA or AAC file with no flag or suggestion that it may not really be the stated extension. Hence my idea of a prompt to import it anyway, though I agree most people will go for a prompt if there is one and end up disappointed. (Yes, I know M4A is importable on Mac with 1.3.3, which is why some perceive it as unjust that WMA is not similarly importable on Windows). So shall we leave it as it is because a prompt will raise false expectations? | > I may be missing something but I am not sure why in the above proposal | > "Open based on extension" should think that it can or should open .doc, | > whereas it correctly thinks from the extension that it can't open WMA. | | Wma is in a specific exclusion list. .doc isn't. So why *isn't* .doc in a specific exclusion list i.e. one that throws an error that says hang on, this is not actually audio? As for other formats I suppose there is a chance an AC3 might be misnamed as an MP3 that makes it worth trying to import as we now do. But I'd have thought for the niche formats like Wavpack, Monkeys, Musepack etc. where people are presumably knowledgeable and wouldn't misname files, these should be on the exclusion list, so get the specific message that these are not supported. MIDI should probably be on the exclusion list as well, there is no sense in the suggestion that the user should try Import Raw. There is a mention of MIDI at the bottom of: http://audacity.sourceforge.net/help/faq?s=files&i=wma-proprietary | > While on about formats I'd like to raise again (not as an essential) the | > issue that Audacity seems to have great difficulty opening compressed | > files inside WAV containers such as are commonly saved by portable | > recorders. | Not for the release checklist page, but not one to lose track of either. The problem is actually that we probably *will* lose sight of it if we don't have it as "a not aiming issue fix" on the checklist or at least somewhere. Is it not best now to push the not-aimings to their own page with just a link thereto so that the checklist itself becomes more digestible? | As a first step, is it appropriate to make a FAQ entry about it? Yes I had this down (in the form of "Audacity supports WAV or AIFF but won't import mine" - so it' s more general and reflects how the question is often thrown at us). But I would hope in the case of the file I posted it should not be *that* difficult to discover why Audacity cannot import it when IMA ADPCM is already supported. Thanks Gale Outbound message virus free. Tested on: 8/24/2007 8:35:31 AM |
From: Alan H. <gi...@as...> - 2007-08-24 08:44:08
|
On Friday 24 August 2007 08:35, Gale Andrews wrote: > | From James Crook <cr...@in...> > | Thu, 23 Aug 2007 09:46:55 +0100 > | Subject: [Audacity-devel] Provide 'Unrecognised Audio File Format' > | dialog with help-link button > > | There's also a > | question in my mind about users who are not connected to the internet > | at that time... > > I completely agree but if we move to having no inbuilt help in 1.4.0 as has > been suggested, this problem will get worse. From what I understand a lot > of folks out "in the sticks" in USA are still on dial-up? The salient > content of the webpage above is 3 paragraphs - is it too much for a program > popup? I realise this is a bit of a side issue to this thread, but are you really suggesting that in the future Audacity will need an internet connection to function fully? In the Linux Audio world it is fairly standard to disable all network functionality for critical audio work, and I believe most dedicated audio workstation distros are cut-down in this way. At least it would be best to have the option at build time to build-in the help pages etc, perhaps by downloading them at build time? Regards Alan |
From: Gale A. <ga...@au...> - 2007-08-25 02:17:13
|
| From Alan Horstmann <gi...@as...> | Fri, 24 Aug 2007 09:50:05 +0100 | Subject: [Audacity-devel] Provide 'Unrecognised Audio File Format' | dialog with help-link button | On Friday 24 August 2007 08:35, Gale Andrews wrote: | > | From James Crook <cr...@in...> | > | Thu, 23 Aug 2007 09:46:55 +0100 | > | Subject: [Audacity-devel] Provide 'Unrecognised Audio File Format' | > | dialog with help-link button | > | There's also a | > | question in my mind about users who are not connected to the internet | > | at that time... | > | > I completely agree but if we move to having no inbuilt help in 1.4.0 as has | > been suggested, this problem will get worse. From what I understand a lot | > of folks out "in the sticks" in USA are still on dial-up? The salient | > content of the webpage above is 3 paragraphs - is it too much for a program | > popup? | | I realise this is a bit of a side issue to this thread, but are you really | suggesting that in the future Audacity will need an internet connection to | function fully? In the Linux Audio world it is fairly standard to disable | all network functionality for critical audio work, and I believe most | dedicated audio workstation distros are cut-down in this way. At least it | would be best to have the option at build time to build-in the help pages | etc, perhaps by downloading them at build time? The new Manual for 1.4 will be a PDF and RTF. The last time we discussed this as far as I can recall, the assumption was that this means the end for the separate "Reference" section built into the program that duplicates part of the Manual, at least in HTML form. Naturally the Manual will be available to download, although I still think it important that it's actually in the Windows and Mac installers for bundlers and mirrors. I am assuming though that it won't be accessible inside the program - have we thought if there will be a button in Audaicty to seek the PDF version on the drive and then load it with the user's PDF client, or is that even practical? Meantime we can cope with the few buttons that load HTML pages as James suggested. Gale Outbound message virus free. Tested on: 8/25/2007 3:17:14 AM |
From: James C. <cr...@in...> - 2007-08-25 10:31:21
|
Gale Andrews wrote: > The new Manual for 1.4 will be a PDF and RTF. The last time we discussed this > as far as I can recall, the assumption was that this means the end for the > separate "Reference" section built into the program that duplicates part of the > Manual, at least in HTML form. Naturally the Manual will be available to > download, although I still think it important that it's actually in the Windows > and Mac installers for bundlers and mirrors. I am assuming though that it > won't be accessible inside the program - have we thought if there will be a > button in Audacity to seek the PDF version on the drive and then load it > with the user's PDF client, or is that even practical? Meantime we can cope > with the few buttons that load HTML pages as James suggested. If we know where the pdf manual is, opening a browser to open a pdf is easy. Most users have Adobe-pdf-reader for their browser, and I think it's fair to assume it. Does anyone know, is there an easy way to open a particular page of a pdf manual? Can we have a discussion/decision on whether to include the manual in the windows/Mac download? My vote would be yes. --James. |
From: David R. S. <dav...@sh...> - 2007-08-25 20:34:29
|
Hi, For what it's worth from one screen reader "viewpoint" - I don't like pdf files. They may be visually pleasing and/or easy to read, but I find them very difficult to read, whether using an Adobe pdf reader, or when I convert the pdf file to a text file and read it on my other computer - there are never any paragraph breaks, and sometimes text that is supposed to be at the bottom or end of the file gets put at the top of the file - very confusing! In other words, I personally prefer plain-text-based code, whether HTML, or even a Word document, which converts cleanly into plain text. Slightly different subject - regarding "online" reference manuals - I don't connect to the net using my Audacity computer. I suspect I'm in a small minority on this last point. :-) Thanks David -- David R. Sky http://www.shellworld.net/~davidsky/ On Sat, 25 Aug 2007, James Crook wrote: > > > Gale Andrews wrote: > >> The new Manual for 1.4 will be a PDF and RTF. The last time we discussed this >> as far as I can recall, the assumption was that this means the end for the >> separate "Reference" section built into the program that duplicates part of the >> Manual, at least in HTML form. Naturally the Manual will be available to >> download, although I still think it important that it's actually in the Windows >> and Mac installers for bundlers and mirrors. I am assuming though that it >> won't be accessible inside the program - have we thought if there will be a >> button in Audacity to seek the PDF version on the drive and then load it >> with the user's PDF client, or is that even practical? Meantime we can cope >> with the few buttons that load HTML pages as James suggested. > > If we know where the pdf manual is, opening a browser to open a pdf is > easy. Most users have Adobe-pdf-reader for their browser, and I think > it's fair to assume it. > > Does anyone know, is there an easy way to open a particular page of a > pdf manual? > > Can we have a discussion/decision on whether to include the manual in > the windows/Mac download? My vote would be yes. > > --James. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Gale A. <ga...@au...> - 2007-08-26 00:19:53
|
| From "David R. Sky" <dav...@sh...> | Sat, 25 Aug 2007 13:34:30 -0700 (PDT) | Subject: [Audacity-devel] pdf files and online reference material was Re: | Provide 'Unrecognised Audio File Format' dialog with help-link button | David: | For what it's worth from one screen reader "viewpoint" - I don't like pdf | files. They may be visually pleasing and/or easy to read, but I find them | very difficult to read, whether using an Adobe pdf reader, or when I | convert the pdf file to a text file and read it on my other computer - | there are never any paragraph breaks, and sometimes text that is supposed | to be at the bottom or end of the file gets put at the top of the file - | very confusing! We had a discussion about this back in May: http://www.nabble.com/Accessibility-of-pdf-manual-t3447312.html#a10821806 and it seems that a tagged PDF Manual should solve most screen reader problems though it won't be updatable automatically. We were also considering a single page HTML version of the Manual which is never going to look as nice as PDF but is another more accessible option. I think we should have that HTML version available. Would accessing that as a local copy be useful as a fallback routine if accessing the PDF does not work? | > On Sat, 25 Aug 2007, James wrote: | > If we know where the pdf manual is, opening a browser to open a pdf is | > easy. Most users have Adobe-pdf-reader for their browser, and I think | > it's fair to assume it. I am not sure if this may be a problem with Foxit PDF reader and Firefox, as Foxit does not support operating as a plug-in inside Firefox (it does work as a plug-in inside IE). Foxit is fairly common on Windows and recommended e.g. by PC Mag above the relatively bloated and slow Adobe, and has a Linux version. Double-clicking a PDF associated with Foxit will open the Foxit app. as a standalone, not a web-browser, even if IE is the default browser. Gale Outbound message virus free. Tested on: 8/26/2007 1:19:54 AM |
From: David R. S. <dav...@sh...> - 2007-08-26 05:20:44
|
On Sun, 26 Aug 2007, Gale Andrews wrote: > We had a discussion about this back in May: > http://www.nabble.com/Accessibility-of-pdf-manual-t3447312.html#a10821806 > Hi Gale, Thanks for the link, I'll examine the rtf and other documents. You had this discussion some time before I came back from my Audacity/Nyquist vacation. We were also > considering a single page HTML version of the Manual which is never going > to look as nice as PDF but is another more accessible option. I think we should > have that HTML version available. Would accessing that as a local copy be > useful as a fallback routine if accessing the PDF does not work? Indeed! Better than pdf (for me). Thanks Gale, David |
From: Richard A. <ri...@au...> - 2007-08-26 14:08:58
|
On Sun, 2007-08-26 at 01:19 +0100, Gale Andrews wrote: > | > On Sat, 25 Aug 2007, James wrote: > | > If we know where the pdf manual is, opening a browser to open a pdf is > | > easy. Most users have Adobe-pdf-reader for their browser, and I think > | > it's fair to assume it. > > I am not sure if this may be a problem with Foxit PDF reader and Firefox, as > Foxit does not support operating as a plug-in inside Firefox (it does work > as a plug-in inside IE). Foxit is fairly common on Windows and recommended > e.g. by PC Mag above the relatively bloated and slow Adobe, and has a Linux > version. Double-clicking a PDF associated with Foxit will open the Foxit app. as > a standalone, not a web-browser, even if IE is the default browser. Gets even more hairy on Linux, where Adobe is probably the least likely viewer to have available - with Evince / Gpdf / Kpdf / Xpdf all likely depending on desktop and user preferences. I'm sure I've seen Foxit running as a firefox plug-in on windows in the past, although it wasn't my machine. Might be it needs some configuration or a newish version to work - I do recall it not working first time. Either of these does assume that web links from within audacity can be made to work on Linux - currently the "Download free copy of LAME" link in the preferences does nothing at all when I press it (and gives me no error message either (including on the console)). I think in both cases there ought to be a way of asking the system to open a given URL or file in the appropriate application it knows about, which I think is XDG / freedesktop.org's portland project, although I may be wrong. Richard |
From: Gale A. <ga...@au...> - 2007-08-27 23:39:49
|
| From Richard Ash <ri...@au...> | Sun, 26 Aug 2007 15:08:50 +0100 | Subject: [Audacity-devel] pdf files and online reference material | On Sun, 2007-08-26 at 01:19 +0100, Gale Andrews wrote: | > Foxit does not support operating as a plug-in inside Firefox (it does work | > as a plug-in inside IE). Foxit is fairly common on Windows and recommended | > e.g. by PC Mag above the relatively bloated and slow Adobe, and has a Linux | > version. Double-clicking a PDF associated with Foxit will open the Foxit | > app. as a standalone, not a web-browser, even if IE is the default browser. | | Gets even more hairy on Linux, where Adobe is probably the least likely | viewer to have available - with Evince / Gpdf / Kpdf / Xpdf all likely | depending on desktop and user preferences. | | I'm sure I've seen Foxit running as a firefox plug-in on windows in the | past, although it wasn't my machine. Might be it needs some | configuration or a newish version to work - I do recall it not working | first time. Well for the record I did eventually get a Foxit PDF plug-in working in Firefox but the official Foxit and Firefox opinion seems to be that this is not supported. I eventually found a downloadable copy of the plug-in here: http://www.pdfdownload.org/foxItPlugin/firefoxit.zip and instructions for installing it here: http://foxitsoftware.com/bbs/showpost.php?p=5259&postcount=26 It's still buggy though, as once you have a PDF open in a Firefox tab you cannot use any other tabs until you close the PDF. There is also a Firefox add-on: https://addons.mozilla.org/en-US/firefox/addon/636 that gives you an option to view PDF documents from the web as HTML by downloading it to an external mirror. The Foxit plug-in is not needed to view PDF as HTML in this way. But I don't see a way to set Foxit to load a local PDF in a broswer plug-in without forcing the association, and I am sure Adobe can be set to open a local PDF in the reader itself. And supposing the user chooses when installing the PDF reader not to install a browser plug-in? This is definitely optional in Foxit. I can't see we will get away with just opening a browser, and shouldn't we have a fallback for PDF that is locally accessible anyway, such as the all-on-one-page HTML idea? Gale Outbound message virus free. Tested on: 8/28/2007 12:39:47 AM |
From: Gale A. <ga...@au...> - 2007-08-27 23:43:29
|
| From Richard Ash <ri...@au...> | Sun, 26 Aug 2007 15:08:50 +0100 | Subject: [Audacity-devel] pdf files and online reference material BTW - a gentle reminder our 1.3.3 Manual: http://audacityteam.org/manual/export/AudacityManual.pdf is still corrupted. Gale Outbound message virus free. Tested on: 8/28/2007 12:43:28 AM |
From: Vaughan J. <va...@au...> - 2007-08-27 22:26:07
|
James Crook wrote: > Gale Andrews wrote: > > >> The new Manual for 1.4 will be a PDF and RTF. The last time we discussed this >> as far as I can recall, the assumption was that this means the end for the >> separate "Reference" section built into the program that duplicates part of the >> Manual, at least in HTML form. Naturally the Manual will be available to >> download, although I still think it important that it's actually in the Windows >> and Mac installers for bundlers and mirrors. I am assuming though that it >> won't be accessible inside the program - have we thought if there will be a >> button in Audacity to seek the PDF version on the drive and then load it >> with the user's PDF client, or is that even practical? Meantime we can cope >> with the few buttons that load HTML pages as James suggested. >> > > If we know where the pdf manual is, opening a browser to open a pdf is > easy. Most users have Adobe-pdf-reader for their browser, and I think > it's fair to assume it. > My only grouse about PDF is that Acrobat Reader is such bloatware and takes so long to start up. PDF is pretty much the standard, but I prefer HTML. > Does anyone know, is there an easy way to open a particular page of a > pdf manual? > > Can we have a discussion/decision on whether to include the manual in > the windows/Mac download? My vote would be yes. > > PDF files are also quite big for their content, so although I think it should be in the installer, it might be good to offer a sleeker installer without the manual, and a separate d/l for the manual. - Vaughan |
From: Martyn S. <mar...@go...> - 2007-08-28 00:07:10
|
Vaughan Johnson wrote: > James Crook wrote: >> Gale Andrews wrote: ... > My only grouse about PDF is that Acrobat Reader is such bloatware and > takes so long to start up. Me too! I won't click on them, unless I can't get the information any other way! Boo to pdf (does pdf stand for 'Prompt Delivery Failed'?). Martyn (feeling slightly childish) |
From: <bu...@gm...> - 2007-08-29 02:22:16
|
Martyn Shaw <mar...@go...> said on Aug 27, 2007 20:07 -0400 (in part): > Vaughan Johnson wrote: > >> > James Crook wrote: >> >>> >> Gale Andrews wrote: >>> > ... > >> > My only grouse about PDF is that Acrobat Reader is such bloatware and >> > takes so long to start up. >> > > Me too! I won't click on them, unless I can't get the information any > other way! What version of Adobe Acrobat reader are you AR-haters :-) using? My WinXP machine has 2 GB RAM, 2.2 GHz and I've got Acrobat Reader 8.1.0. so granted its not terribly underpowered but still ... I just tested - it opened the 21 MB Gimp 2.4 manual (PDF format) in about 10 seconds, and then immediately following that a 2 MB PDF file in two seconds. Closing the Gimp manual and reopening it only took about 3 seconds. I remember back in the day (Acrobat 4.x, 5.x) using FoxIt and the other programs/techniques to remove all the bloat that came with Acrobat but either they've cleaned up their act or my machine is a lot more powerful than the ones I was using back with Win9x / Win2k ( used to be 233 Mhz / 733Mhz respectively - or both?) I've got no problem at all with Acrobat Reader these days. The ver 8 UI is nice and the search functions are a treat. Even opening fairly substantial PDF files from browser links (in either Firefox 2 or IE-7) isn't a big time waster any more. Just my $0.02 Regards ... Alec -- buralex-gmail -- |
From: Martyn S. <mar...@go...> - 2007-08-31 00:52:43
|
Alec I have a similar setup here and found a 2Meg pdf that was fine, in terms of speed. At work I have an earlier version of Acrobat Reader that takes ages to load, and can't update it. When it does load pages it does something silly with the scaling so I can't read the writing. Zooming in isn't much better. Browsing around is tedious - it's like looking at a document down a tube or with my wife's reading glasses on; makes me feel sick after a short time. <rant>Many sites have pdfs that are poorly scanned paper-based documents (they look like faxes) which aren't worth waiting for - I can only assume that they are done by idiots who need to say to their equally incompetant bosses 'I've put it up on the web site' so that they can go home.</rant> These must put other people off, as well as me. For me, xhtml is better; I can scale the font (locally, so it wraps), copy, paste, print easily (admittedly 'print' may not be as good). I believe that accessibility is easier and anybody with a web browser can read it. It's not that I hate pdfs, if I want to print something out, such as a service manual for the washing machine, then they are fine. But on screen? At 1024x768? A4 paper must be about 3000xsomething or more. Appropriate means for the medium, I say, and people using Audacity are on a computer of some sort aren't they? Just my £0.01 (exchange rates aren't what they were are they?) TTFN Martyn bu...@gm... wrote: > Martyn Shaw <mar...@go...> said on Aug 27, 2007 20:07 > -0400 (in part): >> Vaughan Johnson wrote: >> >>> > James Crook wrote: >>> >>>> >> Gale Andrews wrote: >>>> >> ... >> >>> > My only grouse about PDF is that Acrobat Reader is such bloatware and >>> > takes so long to start up. >>> >> >> Me too! I won't click on them, unless I can't get the information any >> other way! > What version of Adobe Acrobat reader are you AR-haters :-) using? My > WinXP machine has 2 GB RAM, 2.2 GHz and I've got Acrobat Reader 8.1.0. > so granted its not terribly underpowered but still ... > > I just tested - it opened the 21 MB Gimp 2.4 manual (PDF format) in > about 10 seconds, and then immediately following that a 2 MB PDF file in > two seconds. > > Closing the Gimp manual and reopening it only took about 3 seconds. > > I remember back in the day (Acrobat 4.x, 5.x) using FoxIt and the other > programs/techniques to remove all the bloat that came with Acrobat but > either they've cleaned up their act or my machine is a lot more powerful > than the ones I was using back with Win9x / Win2k ( used to be 233 Mhz / > 733Mhz respectively - or both?) I've got no problem at all with Acrobat > Reader these days. The ver 8 UI is nice and the search functions are a > treat. > > Even opening fairly substantial PDF files from browser links (in either > Firefox 2 or IE-7) isn't a big time waster any more. > > Just my $0.02 > > Regards ... Alec -- buralex-gmail > -- > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Gale A. <ga...@au...> - 2007-08-31 01:53:58
|
| From Martyn Shaw <mar...@go...> | Fri, 31 Aug 2007 01:46:27 +0100 | Subject: [Audacity-devel] Provide 'Unrecognised Audio File Format' | dialog with help-link button | I have a similar setup here and found a 2Meg pdf that was fine, in terms | of speed. At work I have an earlier version of Acrobat Reader that | takes ages to load, and can't update it. When it does load pages it | does something silly with the scaling so I can't read the writing. | Zooming in isn't much better. Browsing around is tedious - it's like | looking at a document down a tube or with my wife's reading glasses on; | makes me feel sick after a short time. | For me, xhtml is better; I can scale the font (locally, so it wraps), | copy, paste, print easily (admittedly 'print' may not be as good). I | believe that accessibility is easier and anybody with a web browser can | read it. | It's not that I hate pdfs, if I want to print something out, such as a | service manual for the washing machine, then they are fine. But on | screen? At 1024x768? We don't have the 1.3.3 manual on PDF but how does our PDF of the 1.2.x look on your work-based AR? I think we must assume some users will have old versions they can't be bothered to update? How does it look on your home PC? http://www.gaclrecords.org.uk/audacity-manual-1.2.pdf Foxit's search is just like search in Internet Explorer, one result at a time and no way to get a list, so it is not the nicer search we have in the help built into 1.2.x. I don't especially like PDF and I won't get AR for search capability, whatever it is. I often have to read hardware manuals in PDF to try and help users and often their pages are side by side like a book so I have to zoom to read it and endlessly scroll from side to side. OK, we won't do it like that, but I am not quite convinced PDF should be the default way users get help in Audacity or that the many novices we acquire every day will be comfortable with them. I certainly don't want a mere part of the manual built into Audacity as we now have, but I'm still unsure about removing inbuilt help altogether or making it dependent on either PDF or an internet connection. Gale Outbound message virus free. Tested on: 8/31/2007 2:53:59 AM |
From: David B. <drb...@go...> - 2007-08-31 10:31:35
|
Hi, My =A30.01: For VI users: A single page of html is more accessible than pdf, but if pdf is used it must be tagged pdf. The only advantage of pdf is for printing - page nos, don't get headings as the last line on a page, etc. David. |
From: Martyn S. <mar...@go...> - 2007-09-01 22:03:28
|
Gale Andrews wrote: ... > We don't have the 1.3.3 manual on PDF but how does our PDF of the > 1.2.x look on your work-based AR? I think we must assume some users > will have old versions they can't be bothered to update? How does it > look on your home PC? I'm at home, with AR 8.1.0. But you did ask so... It looks like it needs printing out (but then the links won't work); that is the pages look like pages of a manual, they have page numbers. It is portrait, my screen is landscape. The font is not very good for reading on screen. When I resize AR, the text changes size so I can't read it. I have no 'back' button for when I've wandered off somewhere. Some of the formatting is wrong eg on page 4 'Introduction' is overscored, as is 'this section' and 'in this document' is misplaced. Some of the links don't work eg DEF on page 155. In contrast, the 1.2.6 built-in help is great. The font is good, the page re-lays-out when I change the window size, I have a back button that takes me back to the last place I clicked. I could go on, but won't. Martyn |
From: Richard A. <ri...@au...> - 2007-09-01 16:55:30
|
On Fri, 2007-08-31 at 01:46 +0100, Martyn Shaw wrote: > For me, xhtml is better; I can scale the font (locally, so it wraps), > copy, paste, print easily (admittedly 'print' may not be as good). I > believe that accessibility is easier and anybody with a web browser can > read it. > > It's not that I hate pdfs, if I want to print something out, such as a > service manual for the washing machine, then they are fine. But on > screen? At 1024x768? A4 paper must be about 3000xsomething or more. > Appropriate means for the medium, I say, and people using Audacity are > on a computer of some sort aren't they? The problem is that an awful lot of computer illiterate users want to print out "the manual" rather than read it on their screen (and have no idea how to open a local file in a web browser anyway). This was why I started converting the HTML manual for audacity 1.2 into a PDF using a format converter, so that the people who wanted to print the lot didn't have to do each page as they went, and they could download it as a single file (most can't cope with zip archives either). The problem with this approach was two-fold. Firstly, you had to write the manual as HTML, so it was a pain to update (it wasn't very WYSWYG friendly, and the output of most WYSWYG applications wouldn't convert to PDF properly). Secondly, the formatting of the PDF often didn't match the formatting of the HTML, because the converter had lousy style support and ignored most of the formatting. These were the main reasons for moving the manual onto the wiki at http://www.audacityteam.org/manual/index.php?title=Main_Page This makes editing easier (because you don't need to mess with HTML), and it outputs nice, reasonably standards compliant XHTML on the Internet. There is an interface for adding exporters to mediawiki, so the idea (mostly Dominic's) was to use this interface to export other formats we wanted the documentation in, mainly (at that point) PDF. The problem is that PDF export for mediawiki isn't terribly mature (hence why it's currently broken), and there is no good way to do static HTML pages other than by spidering the site, which isn't a terribly good way to do it. The wxHTML viewer gives us another set of problems, because it doesn't support XHTML. It doesn't even do all the things in HTML 4.0, but basically does the cut-down feature set of the Microsoft HTML help browser. This is a pain, because it doesn't (as far as I know) include any style support. So creating content for it is messy and non-standard. This is where the drive to not use the program internal help came from - creating it was a right pain because it won't take content intended for modern web browsers. Richard |
From: Gale A. <ga...@au...> - 2007-09-01 17:36:03
|
| From Richard Ash <ri...@au...> | Sat, 01 Sep 2007 17:55:21 +0100 | Subject: [Audacity-devel] Help Formats (was Provide 'Unrecognised | Audio File Format' dialog with help-link button) | On Fri, 2007-08-31 at 01:46 +0100, Martyn Shaw wrote: | > It's not that I hate pdfs, if I want to print something out, such as a | > service manual for the washing machine, then they are fine. But on | > screen? At 1024x768? A4 paper must be about 3000xsomething or more. | > Appropriate means for the medium, I say, and people using Audacity are | > on a computer of some sort aren't they? | | The problem with this approach was two-fold. Firstly, you had to write | the manual as HTML, so it was a pain to update (it wasn't very WYSWYG | friendly, and the output of most WYSWYG applications wouldn't convert to | PDF properly). Secondly, the formatting of the PDF (made from it) | often didn't match the formatting of the HTML, because the converter | had lousy style support and ignored most of the formatting. | | These were the main reasons for moving the manual onto the wiki at | http://www.audacityteam.org/manual/index.php?title=Main_Page | | This makes editing easier (because you don't need to mess with HTML), | and it outputs nice, reasonably standards compliant XHTML on the | Internet. There is an interface for adding exporters to mediawiki, so | the idea (mostly Dominic's) was to use this interface to export other | formats we wanted the documentation in, mainly (at that point) PDF. | | The wxHTML viewer gives us another set of problems, because it doesn't | support XHTML. It doesn't even do all the things in HTML 4.0, but | basically does the cut-down feature set of the Microsoft HTML help | browser. This is a pain, because it doesn't (as far as I know) include | any style support. So creating content for it is messy and non-standard. | This is where the drive to not use the program internal help came from - | creating it was a right pain because it won't take content intended for | modern web browsers. This is all understood and I think we have to accept that if we were to continue with internal help it would not change between versions, that more up to date help would be on a PDF, and that PDF would be the preferred way to disseminate help. On the other hand the old inbuilt help never updated between versions anyway. The majority of the users (i.e. on Windows) probably find it odd we don't use CHM without realising the reason is that is specific to Windows. Isn't CHM being phased out now with Vista anyway? I don't have "too" much problem having no inbuilt help, with a single page online HTML version infrequently updated for those who have problems with PDF (for reasons of accessibility or otherwise). Obviously those with poor internet connections, or none on the computer they are using Audacity on, will see this as a regression. Also the majority of quality Windows programs in my experience do have inbuilt Help, so the user expectation is there (I don't know if Linux and Mac users have this expectation or not). Gale Outbound message virus free. Tested on: 9/1/2007 6:35:51 PM |
From: Martyn S. <mar...@go...> - 2007-09-02 00:25:11
|
Hi Richard Thanks for clarifying this sorry story. How do these people tie their shoes in the morning? The RTF vesion from http://www.audacityteam.org/manual/index.php?title=Main_Page stands at 198 pages, do they really print it out? I struggle to comprehend. Martyn Richard Ash wrote: > On Fri, 2007-08-31 at 01:46 +0100, Martyn Shaw wrote: >> For me, xhtml is better; I can scale the font (locally, so it wraps), >> copy, paste, print easily (admittedly 'print' may not be as good). I >> believe that accessibility is easier and anybody with a web browser can >> read it. >> >> It's not that I hate pdfs, if I want to print something out, such as a >> service manual for the washing machine, then they are fine. But on >> screen? At 1024x768? A4 paper must be about 3000xsomething or more. >> Appropriate means for the medium, I say, and people using Audacity are >> on a computer of some sort aren't they? > The problem is that an awful lot of computer illiterate users want to > print out "the manual" rather than read it on their screen (and have no > idea how to open a local file in a web browser anyway). > > This was why I started converting the HTML manual for audacity 1.2 into > a PDF using a format converter, so that the people who wanted to print > the lot didn't have to do each page as they went, and they could > download it as a single file (most can't cope with zip archives > either). > > The problem with this approach was two-fold. Firstly, you had to write > the manual as HTML, so it was a pain to update (it wasn't very WYSWYG > friendly, and the output of most WYSWYG applications wouldn't convert to > PDF properly). Secondly, the formatting of the PDF often didn't match > the formatting of the HTML, because the converter had lousy style > support and ignored most of the formatting. > > These were the main reasons for moving the manual onto the wiki at > http://www.audacityteam.org/manual/index.php?title=Main_Page > This makes editing easier (because you don't need to mess with HTML), > and it outputs nice, reasonably standards compliant XHTML on the > Internet. There is an interface for adding exporters to mediawiki, so > the idea (mostly Dominic's) was to use this interface to export other > formats we wanted the documentation in, mainly (at that point) PDF. > > The problem is that PDF export for mediawiki isn't terribly mature > (hence why it's currently broken), and there is no good way to do static > HTML pages other than by spidering the site, which isn't a terribly good > way to do it. > > The wxHTML viewer gives us another set of problems, because it doesn't > support XHTML. It doesn't even do all the things in HTML 4.0, but > basically does the cut-down feature set of the Microsoft HTML help > browser. This is a pain, because it doesn't (as far as I know) include > any style support. So creating content for it is messy and non-standard. > This is where the drive to not use the program internal help came from - > creating it was a right pain because it won't take content intended for > modern web browsers. > > Richard > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |