On Wed, 11 Dec 2002, "Glenn McCorkle" <[EMAIL PROTECTED]> wrote:
> Subject: Re: Printing/export/capture in A171ue > On Tue, 10 Dec 2002 10:22:06 -0800, Bastiaan Edelman, PA3FFZ wrote: >>> Hello Glenn - >> Yes, I agree with Klaus. >> Besides it is not easy (not possible ?) to newbies to alter something in >> mime.cfg or arachne.cfg. So I would suggest that any version should run >> correct whitout modifications by the unexperienced user. >> For printing and other services extra programs are needed which are not >> supplied with Arachne. Maybe they are somewhere in the users computer, >> like pkunzip and pkzip for ZBM's. >> Some are probably not like Gostscript or printerdrivers. >> How would a newbie know what to shop elswere and how and where to >> install these? the newbie simply clicks on the icons and nothing >> happens... what would you do? > I also agree with both of you. > These are problems which need to be solved. > Shall we start with printing? > The problem is little bit complex. :( > While it is true that an outside program is going to be needed for > printing of graphics..... > None is needed for printing of text. > However... what IS needed for text printing is a DOS compatable printer. > (one which does have 'built-in' fonts) > If someone hits P and then clicks the "use device PRN" button, > but they have a WinPrinter. > (no fonts in the printer itself, it must use the WinFonts).... > Nothing will happen. > So, hitting that button if you have a WinPrinter will cause confusion > as to why nothing was printed. > If someone hits P and then clicks the "use PRINT command" button, > but does not have print.com.... Nothing will happen. > So, hitting that button if you are user who doesn't have print.com > will also cause confusion as to why nothing was printed. > I see only one way to fix these 2 situations. > 1) include print.com in our Arachne package. > 2) BURN all WinPrinters <g g g> >> IMHO the "My Computer" should be fixed too... I use 3 computers, 2 with >> 1.61 and 1 with 1.71UE and they all lock-up on this. > Now THAT one is a very MAJOR problem. > May I ask for your assistance in trying to fix it? > I will need some very specific details about your setup(s) on those 3 > machines so that I try to duplicate the lock-ups on my machine. > That's the problem with trying to find the cause and cure of most bugs. > In almost all cases, you can't fix them unless you are actually able > to SEE them happen for yourself. > That's how I was able figure-out that bug with CDROM.IKN being > interpreted by DOS as being the loaded device CDROM. > Since I did not have "CDROM" as the device name... I had no lock-ups. > When I used CDROM as the device name... locked her up tight as a drum. >> Glenn, you did a great job... but there is still some work to be done. >> CU, Bastiaan > Thank you very much. > And yes, you are correct. > There remains much work to be done. > And as you can see from > http://www.angelfire.com/id/glenndoom/ara171ue01.htm > (updated in the wee-hours of this morning)... I am still doing it. ;-) > [**** update *****] > (just now updated again to include most of what we are discussing) > And now in reply to what Klaus had to say. >>> After the recent discussion about printing/exporting from ARACHNE171UE, >>> I was struck by the inconsistent treatment of various capture functions, >>> namely: >>> P = print as text >>> ALT-P = print as Postscript >>> CTL-P = print as BMP or JPG >>> PrntScrn >>> Quite some time ago you sent me a fix for the "print as text" option >>> and which has now been incorporated into the new 171UE. I can't quite >>> remember exactly what is was, but it involved making a change in >>> MIME.CFG. >>> Since I am not sufficiently sophisticated to be able to interpret all >>> of that (in spite of the syntax lesson at the end), I will relate here >>> what I have found out about the capture functions. As you will see, rather >>> similar things are treated quite differently. >>> I will start with ALT-P (print to Postscript) because that works >>> probably somewhat like the others were intended to, namely: >>> as soon as ALT-P is hit, a _4prt.ps file is created in the main Arachne >>> directory irrespective of whether "Export" is selected or not. When "Export" >>> is selected, the Postscript file is copied to the "Export" directory >>> with filename "output.ps" or whatever name the user changes it to. >>> The only problems here are that the _4prt.ps file is NOT ERASED from >>> the main Arachne directory. > Oh... you want to delete it after saving ? > No problem. > (old line) > file/exportps.dgi |[100]COPY _4prt.ps $s>NUL > (new line) > file/exportps.dgi |[100]COPY _4prt.ps $s>NUL \n del _4prt.ps > (do the same at the end of "export.dgi" to delete _4prt.txt) >>> And, probably unrelated, one cannot exit >>> from Arachne with ALT-X from that screen (you have to go back or to another >>> screen). Alt-X gets you out of Arachne from all the other capture screens. >>> In my view similar functions should behave similarly. This is the only one >>> that actually "exports" to the EXPORT subdirectory. And perhaps some >>> indication should be given where to find it (e.g. "Done. Your file >>> is in the EXPORT subdirectory") > Oh... you want to do BOTH ????? > Now you ARE getting demanding. <g> > file/export.dgi >TXT|[100]COPY _4prt.txt $s>NUL > | del _4prt.txt | if exist $s echo file saved>$2 > (^ these are the ^ 2 vertical dashes one above the other) > [On my keybaord, it's a SHFT+\] (line broken for eMailing) > If everything goes well... We will be viewing the reslting TXT file > contianing the words "file saved". > (or any other text we choose to put in there) > If we try to save to a non-existant directory.... We will be viewing > the Arachne load error page. > ____________________________________________________________ > Arachne was unable to load requested URL. Possible reasons: > error in URL > remote host cannot be accesed > remote object does not exist > local file was not found > DGI component is not defined in MIME.CFG > DGI component was not able to create output file > See Arachne documentation for more info. > _____________________________________________________________ > The last of the possible reasons is the one that caused it. > DGI component was not able to create output file > (because the directory we tried to write to did not exist) >>> When the PRNTSCRN key is hit, a BMP graphic file called _4prt.bmp is >>> immediately written in the main Arachne directory as for Alt-P (and in >>> fact, as for all the capture functions). Unfortunately, the copied screen >>> also immediately appears on the terminal with no indication of what has >>> happened, so that the real Arachne header and the IMAGE of the real >>> header (which, of course, doesn't respond to mouse clicks) are seen. If >>> a beginner somehow manages to exit that screen by clicking on the real >>> buttons, he/she still has no way of knowing that the prntscreen image >>> is _4prt.bmp in the main directory (unless he/she is smart enough to >>> have put a line under the old files so he can easily see new, added >>> files; if not, or if the new file writes in the midst of all the >>> other files, good night!). > This only happens when in "full screen mode". > In all other modes, the "top bars" are showing letting the user know > that they are in-fact viewing a BMP file. (with the text in the URL bar > "file://_4prt.bmp" > The only "fix" I can think of for this one is to re-write the code so > that prtbmp.ah will also be called when we hit PrintScreen. > (just as it is now when we hit Cntrl+P) > Or perhaps we can automatically change from "full-screen" mode to one > of the modes which does have the top-bars when PrintScreen is pressed. > (just as-if we had first pressed * and then PrintScreen) >>> CRTL-P (for producing graphic images of the WHOLE on-screen page also >>> produces a _4prt.bmp file which, when "Export" is clicked, is copied to >>> a file called "page.bmp" (or another name if the default name is changed) >>> in the Arachne main directory. Clicking on "Convert to JPG" will convert >>> the _4prt.bmp file to _4prt.jpg BUT NOT if it was previously saved/exported >>> to page.bmp!! Perhaps the buttons could be arranged so that it is clear that >>> ONLY ONE can be clicked and you EITHER export the bmp file OR convert >>> it to JPG. It would also be good to have a chance to name the JPG file, >>> otherwise, with the _4prt.jpg name, the beginner is in the same pickle as >>> described above. None of the Print-JPG, Print BMP, or Save-as-ZBM buttons >>> responded for me (DR-DOS 7.02). Maybe it was my system, but if they are not >>> (yet?) functional, they shouldn't be there, in my view. > Ok, this one is a little easier. > The change is very similar to _4prt.ps and .txt > But instead of taking even more of your time by explaining it here.... > I'll just go ahead and fix it. <g g g> >>> Hitting the P key also immediately writes a _4prt.txt file in the main >>> Arachne directory, which however, if "exported" to the default page.txt, >>> is NOT erased, producing two identical text files. The Preview and Print >>> buttons work ok on my printer (HP Deskjet 540). However, the "Split-Digest" >>> functions seems to me not to belong there since they pertain to e-mail >>> digests. When using Arachne on a RAM disk (drive D:) and not using Insight, >>> clicking on this button sends me to C: leaving behind a text file called >>> _4prt.txt (surprise!) on drive D:. This will be most confusing to a beginner. >>> In sum, I think MIME.CFG should be altered (and maybe rearranged a little >>> so that like functions are grouped together) so that P, ALT-P, CTR-P, and >>> PRNTSCRN all send their output to the EXPORT directory (else what is its >>> purpose?); give a message that something has happened and that the output >>> file is located in the EXPORT directory; and clean up after themselves by >>> deleting the _4prt.??? files. In other words, the capture functions should >>> all behave the same way. >>> I realize that you are putting out brush fires at the moment, and perhaps >>> you think mine are trivial concerns, but I'm always thinking of >>> beginners (since I'm not that far from being one myself) and how to >>> prevent them from responding with the big DEL button (if there were one). >>> Just a suggestion! >>> Klaus Hameyer >>> Burlington, VT (USA) > Thank you both for these suggestions. > Most of them are now included in the updated packages. > http://www.angelfire.com/id/glenndoom/ara171ue01.htm > - -- > Glenn Hold IT..!!!....what we are seeing here is very good technical support, done in a way that we will regret before we go much further along with Arachne use/tweaking/development. Glenn knows how to do this stuff, and he is being exceedingly helpful. And Klaus and Bastiaan are right, to point out things they think are not quite right, or that need to be organized better, or made more consistent....or that they would just LIKE to have included...he he I've done this myself (y'all haven't yet seen my "personalized core" that Glenn cranked out for me the other night...<g g g>...)"...but.. ..but...PEOPLE..!!!!...we can't DO this... 1. First, Glenn cannot really keep track of these changes. There are already so many changes that it's going to take him, and Clarence, and anyotherchangers days/weeks/months to document these changes, and organize them together with the Arachne Packages they need to go with. 2. This is NOW biting us in our collective butts...how do I know...?? Because...I just got bit by one of Glenn's nifty "thingees" (I mean, one of his neat little changes that adds some useful functionality). What bit me..?? Why, Glenns "automagical" pdf2htm conversion script that he put into the MIME.CFG that is in the 1.71ue01 distribution package. That thing made it impossible for me to download/save .PDF files. It just did that to me, tonight...!!! How did it do that...?? The MOME.CFG script calls PDF2HTM.EXE and I do NOT have it in my installation...nor is it a standard part of the Arachne Distro... I am not complaining about the use of PDF2HTM (or the PDF2TXT that is originally defined in that spot in MIME.CFG)...for sure, I download .PDF files for ONE reason only...to CONVERT them...!!!...<g>...BUT.. the pdf2htm is NOT included with the Arachne Package and, if I were a newbie and ran into the problem I ran into tonight, I might run screaming away from Arachne, as my next action in this world....<g g g> 3. BEFORE we dash right out and start including PDF2HTM with the Arachne package, and other such foolish things, we need to realize that we are getting tangled up in one set of standard "project-breaker" "don't do" practices.... What we are doing is "helter-skelter" program modification without any kind of change-approval or change-documentation. SUGGESTIONS: 1. Temporary moratorium on ANY more changes to the 171ue01 package, for ANY reason. 2. Temporary delay the "READY" status that I suggested for 171ue01, and that may have been more-or-less approved by most listers, and maybe even by Michael. We need to STOP, right here...and reassess, before we jump too hasty into releasing a VERY good package....a package that will make itself look stupid, if we release it right now, before we organize it a bit more. 3. We make a tentative "Bug List" of the known, remaining Arachne bugs. 4. We make a "Bug Report Template" for submitting bug reports in a structured, formal way. What we have been doing is our usual (and correct, proper) reporting of glitches to this List, to see if we can get confirmation that we have a "bug"...and, then when it gets confirmed, we fail to do the NEXT step, which is to file a Formal Bug Report...Michael already has such a Report-Template and we must either use that, or use another similar template. AND STICK TO IT, rigorously..!!! We must ALWAYS file one of these FormalBugReports in order to get anyone to work-on/fix any bug....period...final.. 5. We start making a list of the known "Add-on Packages" that go with Arachne (this can be grabbed right off the Arachne download page) and on this list, we need to note what entries in MIME.CFG, ARACHNE.CFG or ANYTHING.CFG, etc go with it. 6. We need a MIME.CFG, with the applicable entries for each individual package, to be included with each said package, along with instructions for installing that package/MIME.CFG... 7. We need to think of some other necessary things to do along the lines of Arachne development, because I am sure that my above thoughts are (1) somewhat disorganized, and (2) incomplete.. <g g g g> ......gregy -- This mail was sent by a user of Arachne - The Ultimate Internet Client
