Hi,
I evaluated MyInfo Standard Version thoroughly these last days and bought the Prof Version. Now I'm a little bit disappointed since export options are far from satisfying, but perhaps it was some wishful thinking on my side, for some part. In the help file, it states :
"[Pro Only] Export topic to a web site
MyInfo allows you to publish a topic as a web site. The exported site has a tree, containing all topic documents, and by clicking on a document title, its text contents shows in the right contents frame.
(...)
5. If you do not want to publish sensitive documents, check the Do not export documents with option and select the minimum sensitivity of the documents you do not want to export. Documents with this or higher sensitivity will not be exported."
I definitely did NOT find any such option (= nor in the dialogue, nor anywhere in global options), so the sensitivity attribute of some docs is not considered but ALL docs in a tree / subtree are exported, whereas I had thought I could interwave the docs to export and my reference docs in one tree, doing the export selection by this sensitivity attribute.
I am currently using the "Professional Version" 5.07 in its PORTABLE variety: Should I install the "real" Prof Version in order to get this missed option, or is the help file simply not correct, and the option is not there?
Somewhere here in the forum it is stated something like, overhaul of the entire export and print functionality is considered in the very near future. I hope very much this will be undertaken, and especially, it would be fine to have that (promised but not yet given?) selective export functionality by an attribute, not only in web export, but in every export, especially in RTF EXPORT, since Microsoft Word is THE standard exchange format between people like us working in an outliner, and 98 p.c. of people who just work in their text "processor"; differenciating your "export pages" from your "reference pages" would thus be very helpful, in order to give them readable documents without your (perhaps confidential) source materials. And in PRINTING, it is exactly the same thing, the same considerations apply: There are pages / elements for "public viewing", and there are your materials that are none of the business of your business partners or other addressees.
In rtf export and in printing, MyInfo allows at this time exporting of flags / no flags / flags or no flags, and I had thought this also was a selective criterion for exporting / printing docs relying on their flag / status, but I got unpredictable results with it, and it seems the meaning is just exporting / printing of the flag / status icon itself, or not, and that it is not meant as a selection of the respective doc for exporting / printing. Anyway, I think relying such a selection on an attribute, might it be the sensitivity attribute only / mandatorily or even, much better, on any attribute or even a combination of two or more attributes, would be much handier.
Thus, please tell me if I have to wait for selective functionality in export / printing, or if there is with web pages in the "real" (= not portable) Prof Version, and if perhaps the flag / state selection was indeed for selecting / deselecting the respective docs, and if I did something bad with it in order to not having the desired results.
In any way, it should be recommendable to ALIGN those selection options in web export / rtf (and plain text, for programming work of course!) / printing, so that ONE strategy for de-select unwanted docs in the tree in all those scenarii would apply.
At this time, I help myself with color "encoding" of these "unwanted" docs; I export the tree into a new one; there I select the colored docs manually (control-click) in order to delete them; then I export / print from there. Of course, I wasn't aware of all this fuss awaiting me in my daily work when I, not knowing the Prof Version, I beat the drum for both versions with such enthousiasm.
If these necessary improvements were just a matter of months, no real problem; if I were stuck with the absence of them definitely, oh my! So please comment.
Exporting / Printing
You are right. This option was removed in some of the last service releases and the help was not updated. We are planning to bring it back along with other export improvements soon. In the next update you will have more control over which pages to export.
I am perfectly happy with this answer for the time being. Having such a control over export / printing is very important for me, and has been the utmost reason for me to choose MI, and for any possible problem which could arise in the programming process I have perfect understanding as long as this functionality is not abandoned. The history of enhancements and improvements of MI, published here, shows and proves that problems are well addressed and resolved; just have a look upon AskSam for example where such problems and "known issues" stay UN-addressed for 10 years and more.
We all have to remember that the WHOLE of the outliner market isn't but a tiny FRACTION of the "word processing" market in its whole, and that WITHIN this tiny fraction there are a hundred of programs struggling with each other, and I made my decision for MI not lightheartedly, and I want to give my contribution to that in some time MI will be the best program of its kind, for I would, as everyone here around, on the receiving end of this quality reached by common effort.
We all have to remember that the WHOLE of the outliner market isn't but a tiny FRACTION of the "word processing" market in its whole, and that WITHIN this tiny fraction there are a hundred of programs struggling with each other, and I made my decision for MI not lightheartedly, and I want to give my contribution to that in some time MI will be the best program of its kind, for I would, as everyone here around, on the receiving end of this quality reached by common effort.
THIS IS MAINLY ABOUT PRINTING...
I
See above, the selection of docs, and the suppression of others, for export and for printing, depending on attributes content (no exporting when tag is "n" or things like that).
This concerns printing, but in fact, the same observations apply to exporting formats as well.
II
In the medium term, it would be helpful to have different print scenarii, that is, to have stored preset print settings with their different options (like in ActionOutline for example).
III
In the short term, those print options should at least be accessible by Alt-key combinations within the print dialogues (= the main print dialogue, and the "Advanced" print dialogue); at this time, some settings / options CAN be accessed by Alt-xyz, but others are not.
Since before II is realized, we have to use external macros in order to have prefigured print settings for different print situations, it would be much easier and much more reliable to have Alt-xyz combinations to trigger, than mouse clicks.
IV
I doubt that the distribution of print options into a main dialogue and an "Advanced" dialogue is helpful. Why? Because when printing, I am shown the main dialogue before doing my Return in order to trigger actual printing, but most of the time, I am not quite sure that I remember well all those options I did in the "Advanced" dialogue, so I have to open that dialogue on top of it, and close it afterwards, just in order to check that I remember my options there well.
Because of this, one big printing dialog for all the printing options would be helpful.
ActionOutline did this in this way, they do sub-dialogs but have a list of chosen options, in order for your opening just those sub-dialogs in which you want to change some option. On the other hand, this is too much fuss also, just do one slightly bigger dialog in which all is there. No need for commentaries in those dialogs, since people would read the help file in order to know what this or that option might be, and then just would want to have those options. If they are done with pull-down lists, no need for a big screen in order to show the print dialogue.
V
At this time, Printing in general is not very "presentable", i.e. printed docs are not very "presentable".
Why? The options in WHAT are: Selected docs, etc., and the options in PRINT are:
- Attributes
- Text
- Attributes and Text
At the same time, there is NO option to have just Text, but without any other attributes except the item's title!
But of course, this would be very helpful to have since most people, most of the time, would want exactly that: To print a document = an item, with its title of course, but without any tags or other attributes.
I know this can be done, by hiding all attributes, one by one, before printing... and then unhiding them, one by one: This is awful !
So at this time, I write the item's title manually into the text pane, before the text, and then after printing I delete it. That's awful too, but it also "solves" some of these problems that follow hereunder.
( I know there is one situation when do NOT want the item's title: When you write a letter. ActionOutline which did not let you choose, let you chosse, indeed, the color and size of the title in printing, and thus, by doing the title in 1 point white, I was able to prefigure a "send letter" setting. It goes without saying that MI should do better than that. )
VI
When printing "Attributes and Text", there is NO blank line between the title (= the title attribute of the item) and the text (= the content of the text pane of the item) - but of course there should be one, normally, but then, not always. (ActionOutline let you choose.) Choosing is important because in fact, you have TWO kinds of printing, continually and one-by-one. One-by-one is for letters and for documents where you want to have one doc a page, in this kind you would put a page break after your docs, and in this case you would want to have a blank line between the title and the text...
... and even, you would want to have a blank line between the title and all other attributes you would want to print, AND between those other attributes, and your text.
The coding implementation would be to do ONE option
a ) "blank line after title / attributes" yes/no, and to do a second thing, allow for
b ) "1. Attributes / 4. Text / 2. Attributes and Text / AND 3. (=in this order) Title and Text" (see IV above),
and then, allow for combinations of a and b. When a) blank line yes and b) 4 Text only, do nothing; when a) blank line and b) 3 "Title and text", there would be just one blank line between title and text, since the other attributes would NOT be printed - and believe me, this option would be used 90 p.c. of all time! -, and when there is a) blank line yes and b) 2 "Attributes and text", there would be a blank line after the title and then again after the other attributes...
IF there are no other attributes in this case, it would be helpful to suppress that second, unwanted line. This detail would be helpful since people would choose "2 Attributes and text" for a range of documents, and only SOME of them would contain other, special attributes / tags, so when there are, there are printed, 1 blank line before, 1 after, and when there are not, only the blank line between title and text would show.
VII
Now for printing of "continual texts". As said before, normally you would want to have printed 1-page docs, like on your screen you have 1-screen docs, and let's face it, this 1-page-an-item principle (=on screen, where you edit, revise, and not only on paper by printing if you want it to be...) is one of the great, great advantages of outliners above normal text processing software.
But indeed, there are some situations on which you want to broke that principle, not on screen, but on printing. Let's say you write for others, for publication (= for export), or just for others to read your stuff. Most of the time, you would want your text to be continuous, since you know that the people reading you have 99,9 p.c. of their reading stuff put in that continuous way (e.g. student papers in university, papers in court...).
Then, and then only, you would NOT opt for "page brake after each doc", but for "special character" / "blank line" (or even two blank lines which is not possible to opt for yet).
But here you would perhaps NOT want a blank line between your title and the body of the item, and that's why the blank line between attributes and text should be optional.
VIII
And finally, the formatting of those titles, 1 item 1 page, or continuous printing. At this time (at least in professional version, and I am always speaking of that version, not of any crippled one), it's for the title "what you see is what you get".
At first glance, this seems to be a good thing, but it s not necessarily so when you take a second glance. In fact, I want to format my items in the tree in a way that helps me in working on them, incl. bold, italics, underline, colors (let alone different font sizes which I never use there).
But in printing / in export, you want it to be NEAT, for reading (= for reading by others, most of the time).
Thus, at this moment, it is not possible to have the title of the document / item in bold formatting, EXCEPT when you do it in BOLD in the TREE: But that's awful: You need to format ALL of your items then in bold in the tree, just to have their titles printed in bold!
When in fact there should be options for formatting the item's titles
(and perhaps the item's other attributes / tags, but the current automatic formatting in italic (and not bold-italic when the item is formatted in bold in the tree) is very acceptable even if there is no option to change that)
because you just need this formatting in a standardized way (and remember, if you format your tree just for the items' titles being formatted the way you want them to be formatted in print, any significance for further reviewing your items will be lost!
IX
In the future, perhaps it would be possible to format the titles for printing, depending on the LEVEL. Since there is a function that NUMBERS these levels / items in printing, it should be possible to adjoin the respective formatting of the item's title to that level.
X
In the meantime, it should be possible to implement an option not just for multiple formatting for different levels of items' titles, but just for ONE formatting of these titles...
XI
And in the meantime for even that rudimentary solution, please do an automatic formatting of titles in Bold (=independently of the formatting in the tree).
XII
Perhaps it would be possible, in the long range, to implement a 2/3/4 column printing option, and also the possibility to print in another font size than is on screen. At this time, I export a lot of docs into MS Word, just in order to print them in 9 point Arial when my texts are in 10 point Arial on-screen in MI (or for texts to be faxed in 12 or 14 point size), and sometimes to have them printed in 3 columns when there are some lists / catalogs of things that do not need to be spread over multiple pages but gain by being held together.
XIII
Finally, for the Headers and Footers. Their options must be accessible by macros / Alt-keys (see III above), and especially, since there is Left - Center - Right for each Headers and Footers, those access combinations must be SIX, not THREE! (Why not do some Alt-1...Alt-6 for this?)
I
See above, the selection of docs, and the suppression of others, for export and for printing, depending on attributes content (no exporting when tag is "n" or things like that).
This concerns printing, but in fact, the same observations apply to exporting formats as well.
II
In the medium term, it would be helpful to have different print scenarii, that is, to have stored preset print settings with their different options (like in ActionOutline for example).
III
In the short term, those print options should at least be accessible by Alt-key combinations within the print dialogues (= the main print dialogue, and the "Advanced" print dialogue); at this time, some settings / options CAN be accessed by Alt-xyz, but others are not.
Since before II is realized, we have to use external macros in order to have prefigured print settings for different print situations, it would be much easier and much more reliable to have Alt-xyz combinations to trigger, than mouse clicks.
IV
I doubt that the distribution of print options into a main dialogue and an "Advanced" dialogue is helpful. Why? Because when printing, I am shown the main dialogue before doing my Return in order to trigger actual printing, but most of the time, I am not quite sure that I remember well all those options I did in the "Advanced" dialogue, so I have to open that dialogue on top of it, and close it afterwards, just in order to check that I remember my options there well.
Because of this, one big printing dialog for all the printing options would be helpful.
ActionOutline did this in this way, they do sub-dialogs but have a list of chosen options, in order for your opening just those sub-dialogs in which you want to change some option. On the other hand, this is too much fuss also, just do one slightly bigger dialog in which all is there. No need for commentaries in those dialogs, since people would read the help file in order to know what this or that option might be, and then just would want to have those options. If they are done with pull-down lists, no need for a big screen in order to show the print dialogue.
V
At this time, Printing in general is not very "presentable", i.e. printed docs are not very "presentable".
Why? The options in WHAT are: Selected docs, etc., and the options in PRINT are:
- Attributes
- Text
- Attributes and Text
At the same time, there is NO option to have just Text, but without any other attributes except the item's title!
But of course, this would be very helpful to have since most people, most of the time, would want exactly that: To print a document = an item, with its title of course, but without any tags or other attributes.
I know this can be done, by hiding all attributes, one by one, before printing... and then unhiding them, one by one: This is awful !
So at this time, I write the item's title manually into the text pane, before the text, and then after printing I delete it. That's awful too, but it also "solves" some of these problems that follow hereunder.
( I know there is one situation when do NOT want the item's title: When you write a letter. ActionOutline which did not let you choose, let you chosse, indeed, the color and size of the title in printing, and thus, by doing the title in 1 point white, I was able to prefigure a "send letter" setting. It goes without saying that MI should do better than that. )
VI
When printing "Attributes and Text", there is NO blank line between the title (= the title attribute of the item) and the text (= the content of the text pane of the item) - but of course there should be one, normally, but then, not always. (ActionOutline let you choose.) Choosing is important because in fact, you have TWO kinds of printing, continually and one-by-one. One-by-one is for letters and for documents where you want to have one doc a page, in this kind you would put a page break after your docs, and in this case you would want to have a blank line between the title and the text...
... and even, you would want to have a blank line between the title and all other attributes you would want to print, AND between those other attributes, and your text.
The coding implementation would be to do ONE option
a ) "blank line after title / attributes" yes/no, and to do a second thing, allow for
b ) "1. Attributes / 4. Text / 2. Attributes and Text / AND 3. (=in this order) Title and Text" (see IV above),
and then, allow for combinations of a and b. When a) blank line yes and b) 4 Text only, do nothing; when a) blank line and b) 3 "Title and text", there would be just one blank line between title and text, since the other attributes would NOT be printed - and believe me, this option would be used 90 p.c. of all time! -, and when there is a) blank line yes and b) 2 "Attributes and text", there would be a blank line after the title and then again after the other attributes...
IF there are no other attributes in this case, it would be helpful to suppress that second, unwanted line. This detail would be helpful since people would choose "2 Attributes and text" for a range of documents, and only SOME of them would contain other, special attributes / tags, so when there are, there are printed, 1 blank line before, 1 after, and when there are not, only the blank line between title and text would show.
VII
Now for printing of "continual texts". As said before, normally you would want to have printed 1-page docs, like on your screen you have 1-screen docs, and let's face it, this 1-page-an-item principle (=on screen, where you edit, revise, and not only on paper by printing if you want it to be...) is one of the great, great advantages of outliners above normal text processing software.
But indeed, there are some situations on which you want to broke that principle, not on screen, but on printing. Let's say you write for others, for publication (= for export), or just for others to read your stuff. Most of the time, you would want your text to be continuous, since you know that the people reading you have 99,9 p.c. of their reading stuff put in that continuous way (e.g. student papers in university, papers in court...).
Then, and then only, you would NOT opt for "page brake after each doc", but for "special character" / "blank line" (or even two blank lines which is not possible to opt for yet).
But here you would perhaps NOT want a blank line between your title and the body of the item, and that's why the blank line between attributes and text should be optional.
VIII
And finally, the formatting of those titles, 1 item 1 page, or continuous printing. At this time (at least in professional version, and I am always speaking of that version, not of any crippled one), it's for the title "what you see is what you get".
At first glance, this seems to be a good thing, but it s not necessarily so when you take a second glance. In fact, I want to format my items in the tree in a way that helps me in working on them, incl. bold, italics, underline, colors (let alone different font sizes which I never use there).
But in printing / in export, you want it to be NEAT, for reading (= for reading by others, most of the time).
Thus, at this moment, it is not possible to have the title of the document / item in bold formatting, EXCEPT when you do it in BOLD in the TREE: But that's awful: You need to format ALL of your items then in bold in the tree, just to have their titles printed in bold!
When in fact there should be options for formatting the item's titles
(and perhaps the item's other attributes / tags, but the current automatic formatting in italic (and not bold-italic when the item is formatted in bold in the tree) is very acceptable even if there is no option to change that)
because you just need this formatting in a standardized way (and remember, if you format your tree just for the items' titles being formatted the way you want them to be formatted in print, any significance for further reviewing your items will be lost!
IX
In the future, perhaps it would be possible to format the titles for printing, depending on the LEVEL. Since there is a function that NUMBERS these levels / items in printing, it should be possible to adjoin the respective formatting of the item's title to that level.
X
In the meantime, it should be possible to implement an option not just for multiple formatting for different levels of items' titles, but just for ONE formatting of these titles...
XI
And in the meantime for even that rudimentary solution, please do an automatic formatting of titles in Bold (=independently of the formatting in the tree).
XII
Perhaps it would be possible, in the long range, to implement a 2/3/4 column printing option, and also the possibility to print in another font size than is on screen. At this time, I export a lot of docs into MS Word, just in order to print them in 9 point Arial when my texts are in 10 point Arial on-screen in MI (or for texts to be faxed in 12 or 14 point size), and sometimes to have them printed in 3 columns when there are some lists / catalogs of things that do not need to be spread over multiple pages but gain by being held together.
XIII
Finally, for the Headers and Footers. Their options must be accessible by macros / Alt-keys (see III above), and especially, since there is Left - Center - Right for each Headers and Footers, those access combinations must be SIX, not THREE! (Why not do some Alt-1...Alt-6 for this?)
ad II / III
Since, attending print scenarii, we have to do with external macros for prefiguring several print settings, we need, as stated, Alt-... access to all printing options.
But then, I've come to see that at least 4 of the "advanced" options are toggles: Alt-b Page break after, Alt-d Custom divider, Alt-i Indent docs, Alt-s Show headings / footers on first page.
Thus, depending on the preceding print scenario, these options are on or off, and when you want to set them to on or off, then, since their previous setting is unknown (to your macro, that is), your setting now is unpredictable.
This being said, there could be implemented the solution to do an Alt-b for Page break after, and then y = yes or n = no, and the same for all of those options.
But there is a more elegant solution perhaps: You could implement an Alt-... accessible "Reset-to-Default" option for ALL options (and in which those 4 options would be set to NO) - before each external macro run for specific settings, then the external macro would do an Alt-r = "Reset to Defaults", and then only it would trigger the "on" settings where needed.
It goes without saying that this "Reset to Defaults" would not need to comprise ALL settings, to some prefigured "default", but that it could be done to a GROUP only of settings: to all that settings that are yes / no = toggles. But then, after all, even the margins are very different, depending on your doc being a letter, or being some internal paper to work on, so your external macro would need to set up even the margins anew every time it sets options, depending on the character of the paper; thus, even prefigured defaults for everything would not harm.
This shows again the need for prefigured print / export settings in MI itself... and then, ^p 1 Return would be a letter, ^p 2 would be continuous printing of all items of the selected branch... - but they should be more than 10, so they should be accessible by letters and / or by digits. But that's easy: Just let us have a list where we can attribute names to given settings (= prefigured setting combinations), and then we could access them by the first letter of these names. L would be a letter then, and we could just put a "2" before a second letter, and so on. So, in general, we would try to give names with different first characters whenever possible, and when not, we would fall back on digits; it would also be possible to do an "L" for the main letter, and then use the following letters, "M" and "N", for alternative letter settings; the same for other formats: "R" for "Report", and then "S" and "T" for alternative report formats...
AND THEN :
Alt-w is:
(1) All docs
(2) Selected branches
(3) Selected docs
(4) Filtered docs
(5) Text pane only
(6) Tree pane
(7) Filter pane
and Alt-r is:
(1) Doc attributes
(2) Doc text
(3) Attributes and text
In any case, it would be very helpful to access those options by Alt-w and then 2, or Alt-r and then 3, for example. (At this time, it is possible to do a Pos1 and then 5 times ArrowDown, e.g., but that's not neat and elegant.)
Since, attending print scenarii, we have to do with external macros for prefiguring several print settings, we need, as stated, Alt-... access to all printing options.
But then, I've come to see that at least 4 of the "advanced" options are toggles: Alt-b Page break after, Alt-d Custom divider, Alt-i Indent docs, Alt-s Show headings / footers on first page.
Thus, depending on the preceding print scenario, these options are on or off, and when you want to set them to on or off, then, since their previous setting is unknown (to your macro, that is), your setting now is unpredictable.
This being said, there could be implemented the solution to do an Alt-b for Page break after, and then y = yes or n = no, and the same for all of those options.
But there is a more elegant solution perhaps: You could implement an Alt-... accessible "Reset-to-Default" option for ALL options (and in which those 4 options would be set to NO) - before each external macro run for specific settings, then the external macro would do an Alt-r = "Reset to Defaults", and then only it would trigger the "on" settings where needed.
It goes without saying that this "Reset to Defaults" would not need to comprise ALL settings, to some prefigured "default", but that it could be done to a GROUP only of settings: to all that settings that are yes / no = toggles. But then, after all, even the margins are very different, depending on your doc being a letter, or being some internal paper to work on, so your external macro would need to set up even the margins anew every time it sets options, depending on the character of the paper; thus, even prefigured defaults for everything would not harm.
This shows again the need for prefigured print / export settings in MI itself... and then, ^p 1 Return would be a letter, ^p 2 would be continuous printing of all items of the selected branch... - but they should be more than 10, so they should be accessible by letters and / or by digits. But that's easy: Just let us have a list where we can attribute names to given settings (= prefigured setting combinations), and then we could access them by the first letter of these names. L would be a letter then, and we could just put a "2" before a second letter, and so on. So, in general, we would try to give names with different first characters whenever possible, and when not, we would fall back on digits; it would also be possible to do an "L" for the main letter, and then use the following letters, "M" and "N", for alternative letter settings; the same for other formats: "R" for "Report", and then "S" and "T" for alternative report formats...
AND THEN :
Alt-w is:
(1) All docs
(2) Selected branches
(3) Selected docs
(4) Filtered docs
(5) Text pane only
(6) Tree pane
(7) Filter pane
and Alt-r is:
(1) Doc attributes
(2) Doc text
(3) Attributes and text
In any case, it would be very helpful to access those options by Alt-w and then 2, or Alt-r and then 3, for example. (At this time, it is possible to do a Pos1 and then 5 times ArrowDown, e.g., but that's not neat and elegant.)
Just a tiny bit: Whenever the advanced printing option "Page break after each document" is ON, you get another blank page at the end of your printing job, be it one page or dozens of pages. It would be nice to NOT "print" another blank page after the LAST printed document / page.
I forgot to mention: Similar problem with Print/Export Options - Delimiters - Custom Divider:
When you printed several items in a row, with such divider lines on the printed pages between the items, after the LAST item, this "custom divider" thankfully and correctly is NOT printed again, BUT if then afterwards, you print single items...
yes, you suspected right, just as mentioned in the above post, here it comes again: It's not an empty page coming out of the printer after your item, it's that "custom divider" line that is printed after the text of the one and only printed page.
***Thus, those delimiter options should be reworked in order to just function BETWEEN items, not after the last one.***
At the same time, this would resolve the problem that up to know, they even appear in a new, single item / single page print job when they have been selected for a former, multi-item print job. It's not handy to have to unselect them before printing single items.
When you printed several items in a row, with such divider lines on the printed pages between the items, after the LAST item, this "custom divider" thankfully and correctly is NOT printed again, BUT if then afterwards, you print single items...
yes, you suspected right, just as mentioned in the above post, here it comes again: It's not an empty page coming out of the printer after your item, it's that "custom divider" line that is printed after the text of the one and only printed page.
***Thus, those delimiter options should be reworked in order to just function BETWEEN items, not after the last one.***
At the same time, this would resolve the problem that up to know, they even appear in a new, single item / single page print job when they have been selected for a former, multi-item print job. It's not handy to have to unselect them before printing single items.
I
I'd like to clarify (it's either this or unpredictable):
a) Individual character(s) as delimiter between items:
- after last item: is not printed (or unpredictable?) = seems NOT faulty (I'm not sure)
- in new print job, after this new print job's last or unique item (when not reset to "none" in the advanced options in the meantime, but what for, this should not be necessary since for this new job it would not be applicable): the delimiter character(s) is / are printed = FAULT
b ) New Page as delimiter between items:
- after last item: is "printed" (= produces unnecessary blank page) = FAULT
- in new print job, after last / unique item: is "printed" (= produces again unnecessary blank page) = FAULT
Might be the same in exporting (not yet verified).
II
As an intermediary delimiter way, as future second or third option, between the special character = first option and the "New Page" = today second, then fourth option, it would be nice to have an option "delimiter line", with several options for the thickness of this line.
Of course, with those "=====" you could do, at this time already, a simili-line, but a really ugly one, and with the character "_____", you could do a "real" line but one which would be shifted down, i.e. would be too far from the preceding item and too close to the following item; of course, you could do a "right" line with that special character "real dash" but it's not easy to accede (Alt plus 4 digits for each character).
And then, it would be nice to also have, as future second or third option, to have the option to have blank lines between different items, with the option to choose how many of them, from 1 to 5 perhaps (2 to 4 would please most users I suppose, I'd choose 3, I assume).
And perhaps, those options could be combined? My dream would be, a blank line, then a rather thin line, then another blank line...
Have a nice weekend; I know I'm overwhelming you with a mountain of little "nasty" things, but then, most of them should have been complained about by fellow users in versions 1, 2, 3, 4 - since they didn't let you know, now it's got a lot in little time, but then, in a few months, there will be a real fine program to be marketed in a professional way. Let your friends criticize you, in order for your potential "adversaries" (= potential customers but that don't buy) having nothing left to complain about!
I'd like to clarify (it's either this or unpredictable):
a) Individual character(s) as delimiter between items:
- after last item: is not printed (or unpredictable?) = seems NOT faulty (I'm not sure)
- in new print job, after this new print job's last or unique item (when not reset to "none" in the advanced options in the meantime, but what for, this should not be necessary since for this new job it would not be applicable): the delimiter character(s) is / are printed = FAULT
b ) New Page as delimiter between items:
- after last item: is "printed" (= produces unnecessary blank page) = FAULT
- in new print job, after last / unique item: is "printed" (= produces again unnecessary blank page) = FAULT
Might be the same in exporting (not yet verified).
II
As an intermediary delimiter way, as future second or third option, between the special character = first option and the "New Page" = today second, then fourth option, it would be nice to have an option "delimiter line", with several options for the thickness of this line.
Of course, with those "=====" you could do, at this time already, a simili-line, but a really ugly one, and with the character "_____", you could do a "real" line but one which would be shifted down, i.e. would be too far from the preceding item and too close to the following item; of course, you could do a "right" line with that special character "real dash" but it's not easy to accede (Alt plus 4 digits for each character).
And then, it would be nice to also have, as future second or third option, to have the option to have blank lines between different items, with the option to choose how many of them, from 1 to 5 perhaps (2 to 4 would please most users I suppose, I'd choose 3, I assume).
And perhaps, those options could be combined? My dream would be, a blank line, then a rather thin line, then another blank line...
Have a nice weekend; I know I'm overwhelming you with a mountain of little "nasty" things, but then, most of them should have been complained about by fellow users in versions 1, 2, 3, 4 - since they didn't let you know, now it's got a lot in little time, but then, in a few months, there will be a real fine program to be marketed in a professional way. Let your friends criticize you, in order for your potential "adversaries" (= potential customers but that don't buy) having nothing left to complain about!
I
Another precision: 9 times out of 10, even the "special character(s) is / are printed after the last item, but not always, and I have the feeling that with "page break" it's the same. (Of course, page break is first, special character(s) is second at this time, my fault to confound them, but then, perhaps the best logic would be the other way round, from "minimal delimiter" to "maximum delimiter". (That's just a detail.)
II
There's another detail to be considered: I finish all my items with a Return, i.e. with a blank line. When such a blank line finishes an item, doing additional blank lines after the item is a little bit unpredictable if sometimes, you forget your final blank line under the item; in fact, as things are, because of my usual blank line of the end (of items), I HAVE my blank line BEFORE the (= artificial) delimiter "line" (see above)... but not AFTER it!
Thus, an "intelligent" solution would be for the printing / exporting program to verify if the item ends with a blank line (= one or more blank lines) or not, and to SUBSTRACT that blank line from the "wanted" blank line in the printing / exporting dialogue, before the delimiter line, but then, if this is too much programming fuss for too little effect, no real problem, just do this:
In fact, I have an idea: Do the option "blank line(s) (= in fact, 1 or 0 would suffice in practice for 99 p.c. of users, even for me ), ABOVE the option "line" (with several options for its strength, I hope; if not, rather thin, please! In fact, I could do without any choice if it's thin enough!), and then, do ANOTHER option "blank line"!
And then, make these three options COMBINABLE!
The effect would be, if somebody, like me, does a blank line beneath his items, he would NOT opt for the first "blank line" option, then he would opt for "line", and then he would opt for "blank line" (= the blank line between the line and the next item), which would give, for result, item a, blank line, thin line, blank line, item b; somebody who does not end his items with a blank line, would pick out all three options, which would give him the same result: item a, blank line, thin line, blank line, item b... and somebody who would like just one or two blank lines, without the thin line... ad infinitum, you got the message.
This is elegant programming for elegant results, without even having to consider if a user does blank lines after his items or not, just let him choose blank line, thin line, AND a second blank line or not, in any combination, and the problem is solved!
This way, the future options would be:
1 ) special character (s) (= alone)
2 ) blank line
3 ) thin line
4 ) blank line ( = 2-4 combinable but not with 1) or 5) )
5 ) new page (alone)
Another precision: 9 times out of 10, even the "special character(s) is / are printed after the last item, but not always, and I have the feeling that with "page break" it's the same. (Of course, page break is first, special character(s) is second at this time, my fault to confound them, but then, perhaps the best logic would be the other way round, from "minimal delimiter" to "maximum delimiter". (That's just a detail.)
II
There's another detail to be considered: I finish all my items with a Return, i.e. with a blank line. When such a blank line finishes an item, doing additional blank lines after the item is a little bit unpredictable if sometimes, you forget your final blank line under the item; in fact, as things are, because of my usual blank line of the end (of items), I HAVE my blank line BEFORE the (= artificial) delimiter "line" (see above)... but not AFTER it!
Thus, an "intelligent" solution would be for the printing / exporting program to verify if the item ends with a blank line (= one or more blank lines) or not, and to SUBSTRACT that blank line from the "wanted" blank line in the printing / exporting dialogue, before the delimiter line, but then, if this is too much programming fuss for too little effect, no real problem, just do this:
In fact, I have an idea: Do the option "blank line(s) (= in fact, 1 or 0 would suffice in practice for 99 p.c. of users, even for me
), ABOVE the option "line" (with several options for its strength, I hope; if not, rather thin, please! In fact, I could do without any choice if it's thin enough!), and then, do ANOTHER option "blank line"!And then, make these three options COMBINABLE!
The effect would be, if somebody, like me, does a blank line beneath his items, he would NOT opt for the first "blank line" option, then he would opt for "line", and then he would opt for "blank line" (= the blank line between the line and the next item), which would give, for result, item a, blank line, thin line, blank line, item b; somebody who does not end his items with a blank line, would pick out all three options, which would give him the same result: item a, blank line, thin line, blank line, item b... and somebody who would like just one or two blank lines, without the thin line... ad infinitum, you got the message.
This is elegant programming for elegant results, without even having to consider if a user does blank lines after his items or not, just let him choose blank line, thin line, AND a second blank line or not, in any combination, and the problem is solved!
This way, the future options would be:
1 ) special character (s) (= alone)
2 ) blank line
3 ) thin line
4 ) blank line ( = 2-4 combinable but not with 1) or 5) )
5 ) new page (alone)