diff --git a/doc/Changes in 1.8.1 Beta1-6.txt b/doc/Changes in 1.8.1 Beta1-6.txt new file mode 100644 index 0000000..57214df --- /dev/null +++ b/doc/Changes in 1.8.1 Beta1-6.txt @@ -0,0 +1,116 @@ + +Changes in 1.8.1 Beta 1 - Beta 6 (11 nov 2023 -- 09 dec 2023) +================================= + +* NEW: Significant improvement in image management + - Support for GIF, PNG, JPG, TIF, BMP, WMF, EMF and ICO + - Several image storage options: EmbeddedRTF, EmbeddedKNT, External (Zip or Folder), ExternalAndEmbeddedKNT + - Image viewer + - It is possible to change the visibility of the images in the file + Options: + * ImgDefaultFormatFromClipb, ImgRatioSizePngVsJPG, ImgCompressionQuality, ImgBmpPixelFormat + * ImgFormatInsideRTF + * ImgMaxAutoWidthGoal + * ImgDefaultLinkMode, ImgLinkRelativePath + * ImgUseRecycleBin + * ImgSaveInSubfolders, Keep original file name + * ImgSingleViewerInstance, ImgHotTrackViewer, ImgViewerPath + + ** A detailed explanation of the image management changes is available in "Images_Readme.txt" + +* Drag and drop directly to Editor's content + Now it is possible to drag and drop any file into the editor's own content, in a specific position. + - A new option is offered from the import window: "Insert content at caret position" + + +* Added option to replace bullets by alternative string when pasting as plain text + + By default, Windows replace bullets by a symbol in Cambria Math (something like a big point) plus a tab character + In RTF it is of the form: + \f1\u10625?\f0\tab One + \f1\u10625?\f0\tab Two + + With the new option is possible to replace the symbol and tab characters by other text. By default it is set to "" (empty string) + but can be configured (in keynote.ini) with something like " - ", for example. + + [EditorOptions] + ... + BulletsInPlainText=" - " + + Issue related: #612 don't copy bullets to other apps + + +* Improvements for profiles management | Profiles\Default | Profiles macros + The following improvements have been incorporated to better organize the different files that are used in each profile/session + (See the file 'Profiles.txt') : + + - If KeyNote detects the presence of the "Profiles\Default" subfolder within the folder with the executable (keynote.exe), it will + search in that subfolder for the keynote.ini file and the rest of the files (and if they do not exist, it will add them to that + folder according to is requiring it) + The setup program will establish that subfolder to promote better organization of the files, avoiding mixing and confusing those + files with the rest of the application files and with the configurations of other profiles. The rest of the profiles should also + be created within the "Profiles" folder. Ex: "Profiles\F9" + The setup program will appropriately set the permissions for the Profiles folder. + + - The notehead.rtf and nodehead.rtf files so far have not been specific to the profile configuration, but common to all. + From the new version it is possible to customize one or both files from a profile, adding them to the folder containing the + profile's .ini file. If one of these two files is not found in the profile folder, the application will use the one(s) located + in the main profile folder ("Profiles\Default" or the folder that contains the executable). + + - If within the folder with the .ini files there is a subfolder called 'macros' (e.g. "Profiles\F9\macros"), the macros contained + therein will be loaded, taking preference over those loaded from the main macro folder (\macros) + - This allows to define different automatic execution macros in each configuration. + - When recording new macros it is possible to create them as general or specific to the profile + + +* Fixed: KNT could get hang doing a Search (Find Next or Find All) [IMPORTANT] + It would depend on the presence of several hidden marks in the editor (vinculated to new KNT links or images --since 1.8.1), + the distance between them and the length of the search term... + This error is present since version 1.8.0 + +* Fixed issue #617: Access violation on exit + + Problem was related to the encoding of file .mgr + At the same time has been corrected the names of the files shown in File | Recent file + (similar problem, encoding of .mru file) + +* Fixed issue #621: "Allow only one instance" not working + +* Fixed: Text selection with Shift + left cursor is canceled when crossing a hidden mark + +* Fixed: Convert '"' to '"' in title from web pages + (Related to commit 'Titles from web pages: convert HTML Ascii codes' (5f9dc27e12)) + +* Fixed: newly added nodes do not respect the established zoom + +* Fixed: New KNT Links could jump to an incorrect position + + KNT links that point to a hidden mark look for a certain pattern and ID bookmark. When the application copies text to the + clipboard, it removes the hidden bookmarks. Not doing so could make that if we pasted the text above the one we were pointing to, + the link will find the hidden mark before the correct one. (On the contrary, the cutting operation does need that hidden mark.) + + In normal situations, the hidden mark is maintained by the control RichEdit as we inserted it. But I have found that RichEdit + can alter some of them, adding control tags within the block that we have bounded between \v and \v0 (actually through {\v....} ). + + (This is a problem only when we are looking for the hidden marks through RTF syntax. In most situations, KNT works directly with + hidden characters) + + We may find that an added tag like: + ... \v\''11B2\''12\v0 HELLO + it ends up appearing for example as: + \v\f0\fs16\lang3082\''11B2\''12\v0 HELLO + + We must convert: + "\v\f0\fs16\lang3082\''11B2\''12\v0 HELLO" -> "\f0\fs16\lang3082 HELLO" + + * Minor changes (mainly code style), minor correction in AlertMng + + A small reduction in the size of the executable was obtained. + + +* Fixed: Possible exception on exporting (File | Copy To... or File | Export... with KNT format ) when including plaintext notes + + +* Improvement/correction to the RemoveKNTHIddenCharactersInRTF procedure +* Other minor adjustments + diff --git a/doc/Changes in 1.8.1 Beta6.txt b/doc/Changes in 1.8.1 Beta6.txt new file mode 100644 index 0000000..f2c1a0e --- /dev/null +++ b/doc/Changes in 1.8.1 Beta6.txt @@ -0,0 +1,67 @@ +Changes in 1.8.1 Beta 6 (09 dec 2023) +======================= + +* Images. Added new ini option: ImgViewerPath + Allows to enter an absolute or relative (to keynote.exe) path to an external image viewer + As requested in https://github.com/dpradov/keynote-nf/issues/623#issuecomment-1824929978 + +* Image viewer: added shortcuts for zoom and scrolling + Zoom: + + In + - Out + * 100% + / Adjust + (From Numpad. +, - : if used with Ctrl : greater zoom ratio ) + + Scrolling: + Cursors (if used with Ctrl : greater scrolling) + + Prior, Next : Up/down edge + Home, End : Left/right edge + Ctrl + Home : Upper left corner + Ctrl + End : Lower right corner + + Notes: + * The increments are greater on Zoom in than on Zoom out + * Ctrl can also be used while clicking the zoom in and out buttons + + +* Fixed: Can be difficult to open images inside tables with the internal or an external viewer + Problem described here: https://github.com/dpradov/keynote-nf/issues/623#issuecomment-1845791606 + It is possible to include images in the cells of a RTF table, but due to the behavior of the RichEdit control, it could be difficult + to open the image (by double clicking, or Ctr+double clicking) because in many cases not only the image is being selected but other + characters in the same cell or row of the board. + It was possible to open it, trying again, but difficult. In hidden images mode (seeing the link to the image) this problem does not + occur and has always worked correctly. + The application is modified to identify and address this situation. Images contained in tables can now be opened normally. + + Important: + Images contained in table cells cannot be resized manually, the RichEdit control does not allow it (can be checked with WordPad). + Instead it will try to perform a drag and drop action. If the image is moved in this way, you will have to reposition it by cutting + and pasting or dragging it again, as you will not be able to Undo. + It is possible to modify the dimensions using the 'Restore image[s] proportions' option or by Alt+Click on the image button, while + selecting this image. If you need to set a size at will and not depend on the 'Max auto. width on insert', perhaps the simplest thing + is to cut and paste the image outside the table, resize it and then reposition it in the table. + + +* Improvements for profiles management | Profiles\Default | Profiles macros + The following improvements have been incorporated to better organize the different files that are used in each profile/session + (See the file 'Profiles.txt') : + + - If KeyNote detects the presence of the "Profiles\Default" subfolder within the folder with the executable (keynote.exe), it will + search in that subfolder for the keynote.ini file and the rest of the files (and if they do not exist, it will add them to that + folder according to is requiring it) + The setup program will establish that subfolder to promote better organization of the files, avoiding mixing and confusing those + files with the rest of the application files and with the configurations of other profiles. The rest of the profiles should also + be created within the "Profiles" folder. Ex: "Profiles\F9" + The setup program will appropriately set the permissions for the Profiles folder. + + - The notehead.rtf and nodehead.rtf files so far have not been specific to the profile configuration, but common to all. + From the new version it is possible to customize one or both files from a profile, adding them to the folder containing the + profile's .ini file. If one of these two files is not found in the profile folder, the application will use the one(s) located + in the main profile folder ("Profiles\Default" or the folder that contains the executable). + + - If within the folder with the .ini files there is a subfolder called 'macros' (e.g. "Profiles\F9\macros"), the macros contained + therein will be loaded, taking preference over those loaded from the main macro folder (\macros) + - This allows to define different automatic execution macros in each configuration. + - When recording new macros it is possible to create them as general or specific to the profile diff --git a/doc/Images_Readme.txt b/doc/Images_Readme.txt new file mode 100644 index 0000000..054ec7b --- /dev/null +++ b/doc/Images_Readme.txt @@ -0,0 +1,572 @@ + +NEW IMAGE MANAGEMENT +========================================== + +Version 1.8.1 of KeyNote NF offers the following improvements in relation to image management: + + + - On systems with recent versions of RichEdit (> 4) KNT makes use of tags that allow images to be embedded in various formats. + In addition to wmetafile8 and emfblip, IT ALLOWS YOU TO USE PNGBLIP OR JPEGBLIP. These last two are much more convenient with images + in formats such as BMP, PNG, JPG, GIF, TIF or PNG. The most obvious thing is that a very significant reduction in the size of the KNT + file is achieved since the RTF format is considerably smaller using pngblip or jpegblip + Remember that in RTF (at least in the implementation available in the RichEdit controls) images are saved in RTF code as Hexadecimal + in ASCII. Something like: + {\pict{\*\picprop}\wmetafile8\picw3888\pich5185\picwgoal2204\pichgoal2940 0100090000038c0000000000760000....} + + - Note: In WordPad, which also uses the RichEdit control, the pngblip or jpegblip formats are not used by default, it does not + incorporate them, although it recognizes them when an RTF file that includes them is opened; yes, giving a warning because by + default it discards them. + + All of these formats are used in KeyNote and, from this version, all images are programmatically inserted into the RichEdit control + using the most appropriate format. + + - It is possible to maintain behavior similar to previous versions, where images continue to be saved embedded in the RTF and therefore + as Hexadecimal in ASCII. But even in this case the situation improves compared to previous versions since: + + - IMAGES ARE ALWAYS INSERTED BY CODE and NOT THROUGH THE CLIPBOARD. In recent versions, only images inserted through drag and drop from + the browser were in png or jpg formats; The WMF and EMF files were not inserted as images but as objects, which when opened were + displayed in Paint. (Older versions of RichEdit didn't even offer png or jpg that way) + + - The menu entry INSERT | PICTURE... now allows you to insert THE MOST COMMON IMAGE FORMATS, although it is more convenient from this + version to use the DRAG AND DROP mechanism, since it is possible to DRAG ANY FILE INTO THE EDITOR'S OWN CONTENT, in a specific position. + - A new option is offered from the import window: "INSERT CONTENT AT CARET POSITION" + If the file (or files) are images, they will be inserted as such, and it will optionally be possible to do so in Link mode. + + + - Images embedded in RTF can continue to be saved for COMPATIBILITY WITH PREVIOUS VERSIONS, but using the new version it is advisable + to use the new storage formats, which make it possible to use other functionalities. + Furthermore, at any time it is possible to change the storage format (towards 'classic', now through the option called Embedded RTF) + on the current file (Save) or on another (Save As), or export all or part of the KNT file to another file, with the embedded RTF images. + + - It is possible to configure one of the following STORAGE MODES for a given file: + + - Embedded RTF: As indicated, this is equivalent to the usual placement of images in RTF files: within the RTF content + itself, as hexadecimal values saved in ASCII. The format of these images is usually wmetafile8, very + voluminous. It would correspond to the image management functionality being disabled. + + - Embedded KNT: Images are located at the end of the KNT file, in binary + This type of storage can be interesting for images to be kept in encrypted KNT files, or when you want + themto be available without depending on another separate file (or folder). + It is more optimal than embedding in RTF code (like ASCII in HEX mode) + + - External: Allows you to select an external storage of one of two types, Zip or Folder. + - Zip: image files are saved in a Zip compressed file format. + Within the configuration options you can select the type of compression (ImgDefaultCompression) that will be used + when adding each new image: Store, Deflate, Deflate64. The first option stores them without applying any compression. + The second option, Deflate, is the most common when adding files to a Zip. + + - Folder: Images will be saved in folders and subfolders in a file system. + + In both cases the images will be created within a subfolder corresponding to the note from which the new image was + inserted for the first time. + + - External + EmbeddedKNT: + It allows to combine the use of images embedded in binary in the KNT file with that of external storage, which + can be Zip or Folder. + + + + * Note. Embedded KNT + In the case of using this type of storage mode with a KNT save format other than the native one, that is, compressed or encrypted, + the following must be taken into account: + - Compression/decompression will not be applied to the final block of the file in which the binary images are embedded. + This speeds up saving and opening the file, especially the first thing, because it is always more expensive to compress + than to decompress. + + - In encrypted mode, images embedded in binary (Embedded KNT), as well as those embedded in RTF (Embedded RTF), YES they are encrypted. + In the event that it is required to ensure image encryption, one of these two modes must be used, since *images saved in external + storage, Zip or Folder, will NOT be encrypted*. + + + - The application allows you to CHANGE THE STORAGE MODE of images of a given file, as well as change from an external Zip storage to + another Folder and vice versa, or point to a new storage location. + + When modifying the storage mode, this change will be made immediatel on all notes and nodes, although it will only become really + effective once the KNT file is saved. At that time the images will be serialized to the KNT file and/or the files will be added to + possible external storage. Once a storage change has been made, the file must be saved to be able to modify it again. + + (It is advisable to have saved existing modifications before changing the storage mode, to ensure you have a complete backup --text and images). + Of course, it is STRONGLY RECOMMENDED to maintain a backup policy, for example by activating the 'Backup at regular intervals' option. + + + - Any EXISTING FILE created from a previous version will be opened using Embedded RTF mode + + - It is possible to define the STORAGE MODE that will be used BY DEFAULT in new KNT files. + + - Operation with INACCESSIBLE EXTERNAL STORAGE + If external storage is used (with External, or External + EmbeddedKNT modes) and it is not available, when trying to view the images + a link will be displayed indicating that it is not available (*). It will still be possible to add new images although provisionally + [only] in the EmbeddedKNT format (although the general mode used is only External) + + This will allow you to work with the KNT file from a location where the storage is temporarily inaccessible. + This could happen, for example, if we use a folder on our work computer as external storage and we want to use the KNT file from home + without having to take all the images with us at the same time. Back on the work computer, at the time of saving, if you already have + access to the folder (or Zip) the images previously incorporated will be added to it. If the storage mode is External (and not + External + EmbeddedKNT), that image will no longer be saved embedded in binary at the end of the KNT file. + Something similar will happen with the deletion of images. If all instances of an image are removed and external storage is not available + to delete the file, the deletion will be done when access to the storage is resumed. + + In addition to a situation like the one described, this behavior can be used to allow it to function even if there are temporary network + outages that could prevent access to external storage. + + (*) If External + EmbeddedKNT is used, the image can always be displayed + + + - WHEN EXPORTING to RTF format the images will be included embedded in RTF (usual way) + - When exporting to KNT format, three possibilities will be considered, as established in the configuration options: + - Include images in 'classic' mode: embedded in RTF + - Include images in Embedded KNT mode + - Do not include images. A link will be displayed instead + + - WHEN IMPORTING NOTES from a KNT FILE on disk (with Tools | Merge Notes) or dragging KNT files, the application incorporates the images + of the new notes, adapting them to the storage mode of the current file. + + + - In notes configured as PLAIN TEXT AND IN VIRTUAL CONTENT NODES *NOT* RTF, the insertion of images is prevented + + - In VIRTUAL NODES LINKED TO RTF FILES images are allowed, but exclusively the Embedded RTF format will be used, to ensure that it can + continue to be used from outside KNT as usual. + + + - IMAGES and options available + ------------------------------- + - It is possible to include multiple INSTANCES of the same image. + + - The application allows you to CHANGE THE VISIBILITY of the IMAGES of the file (which becomes effective only when it is required to + show each individual note/node). If the option to hide the images is selected, the application hides their content and instead offers + a link from which they can be consulted (with the help of a viewer). + * A similar link will appear next to a referenced image that is not available (storage is not available or the file has been moved + or deleted) + For this purpose, a new menu entry (View | Show Images) is included, as well as a new button in one of the toolbars. + + - Ctrl+Click on Image toolbutton: Force reload of external images + In case any image was modified externally. It is applied only to the images of the active node/note. + + + - A simple IMAGE VIEWER is incorporated that allows one or more images to be opened from independent windows. + With the viewer it is possible: + - Check image details, such as format, dimensions, size (Kb), path or number of instances. + - Modify the image title + - Zoom/change background color (There is also an option that allows to set a default background color for the viewer ) + - Dynamically enlarge the image adjusting it to the size of the window (respecting the proportions) + - Open the image path or the file itself (in case of external images). The latter allows to view the image in a specialized image viewer. + - Save the image to a file + - Scroll through all the images or show the one corresponding to a specific ID. + - Allows keyboard shortcuts for zoom and scrolling: + Zoom: + + In + - Out + * 100% + / Adjust + (From Numpad. +, - : if used with Ctrl : greater zoom ratio ) + + Scrolling: + Cursors (if used with Ctrl : greater scrolling) + Prior, Next : Up/down edge + Home, End : Left/right edge + Ctrl + Home : Upper left corner + Ctrl + End : Lower right corner + + * The increments are greater on Zoom in than on Zoom out + * Ctrl can also be used while clicking the zoom in and out buttons + + Opening the image viewer is done as follows: + - If the image is visible: + - Double clicking on it opens the internal KNT viewer with that image loaded, displayed at 100% + (or reduced if it cannot be displayed in full on the screen) + - CTR + double click directly opens the image from outside KNT, with the program that is associated with its extension. + (This is only possible with Linked images or images saved in external Folder storage) + + - If the image is not visible and a link is being displayed instead: + - The general options defined for URL actions are applied, taking into account that Open corresponds to the opening of the + internal viewer, and Open New to the opening outside of KNT. + Right clicking on the link will always open the internal viewer. + + + - When inserting/registering a new image, the application differentiates between the FORMAT IN WHICH IT WILL KEEP the image, which + will be the format it presents in the case of inserting (or dragging) from a file; and the FORMAT USED TO DISPLAY IT in the RichEdit + control, that is, the one that will be used together with the RTF \pict tag. + + In the first case it is possible to use the GIF, PNG, JPG, BMP, TIF, WMF, EMF and ICO formats. If the image is added as Linked + (not 'owned'), only a reference to the original file will be maintained, not the content. If the image is incorporated into the + KNT (owned) file, either through internal storage (EmbeddedKNT) or external storage (EmbeddedExternal: Zip or Folder), the BMP + and ICO formats will be stored previously converted to JPG or PNG; the rest will be stored in the original format, including + WMF or EMF. + + In images obtained from the clipboard, usually from screenshots, the image is found as a Bitmap or Metafile. + In these cases, the format in which it will be saved will be JPG or PNG depending on the ImgDefaultFormatFromClipb and + ImgRatioSizePngVsJPG configuration options. + In the case of identifying new images to incorporate from RTF text processing that includes images, these are mostly found as Metafiles, + with the WMF or EMF formats (normally the first, wmetafile8). These images will be saved converted to JPG or PNG depending on the + configuration options. Normally the images identified in WMF format (wmetafile8) come from clipboard captures, and that is not their + original format, taking up much more size than necessary. Hence the conversion to PNG (preferably) or JPG. + + + * Options: ImgDefaultFormatFromClipb, ImgRatioSizePngVsJPG, ImgCompressionQuality, ImgBmpPixelFormat + The ImgDefaultFormatFromClipb option allows you to choose between PNG or JPG. + The ImgCompressionQuality option allows you to define a quality format to be used with the JPG format: 0 - 100 + The ImgRatioSizePngVsJPG option allows you to select the most appropriate format taking into account the size resulting from the + conversion to both: + + A value > 0 => A conversion will be performed to both formats (Png and Jpg). + If the default format (set by ImgDefaultFormatFromClipb, eg. PNG) is sizer than the alternative format, in a proportion >= to + the value indicated, the alternative format (eg. JPG) will be used + + The ImgBmpPixelFormat option allows you to select the color depth to be considered on the starting bitmap: + pf15bit, pf24bit, pf32bit + + - - - + When the content of a screenshot is directly pasted from the clipboard (for example with Greesnhot), an image (CF_BITMAP) + is detected in the clipboard, and in that case the conversion to PNG is identical and the result takes up much less space. + In these cases, the conversion to PNG probably takes up less space than its conversion to JPEG. + As an example, an image captured from an Explorer window can take up the following (in binary, viewing Stream.Size), approx.: + + - BMP: 775.000 - WMF: 582.000 - PNG: 30700 - JPG: 39.000 (JPG occupies 1.3 times more than the PNG version here) + + ( Images are available on the clipboard on other occasions, for example when selecting an image in a browser and using Copy Image ) + + If that same image is pasted into WordPad and from there it is copied back to the clipboard, at the time of pasting we + will no longer have a bitmap, but a Picture (Metafile). In this case, an image (CF_BITMAP) is not detected in the clipboard, + but rather an embedded object, which gives rise to an image and which we can detect through the generated RTF. We can convert + the image extracted from the RTF. But that conversion, even if it is good, is not as perfect as the one that it occurs when + we directly detect the image, and they take up slightly more. + (Note: A Picture (Device independent bitmap) is offered as CF_BITMAP) + + When what is pasted is the content of a photograph, in that case it is clearly more favorable to use the JPEG format over PNG. + As an example, a relatively small image, of a photograph with much of the image in a soft gradient, without much detail, can + occupy 538,499 in PNG and 34,067 in JPEG (15.8 times more in PNG) + - - - + + A typical screenshot (from an application, file explorer, etc.) can usually be saved without any noticeable color loss, + with pf15bit (with pf16bit it doesn't look good). If the capture includes photographs, or images with color gradients + that we need to maintain, then we must select pf24bit. Under normal circumstances, at least from screenshots, it doesn't make + much sense to use pf32bit, as it will take up more space and you won't see any difference. + It is true that the captures, taken in bitmaps, will be converted to png (or jpg), so the difference between the formats + will not be so big, but there will be one. The difference can be seen when the image has gradients, etc., but in that + case the normal thing will be not to want to lose quality. + If we have quality images then what we should do is drag (or insert) the files to the editor. The image will be displayed + in the best quality allowed by the editor. And we will not touch the file format. + - - - + + + * Option: ImgFormatInsideRTF + In order to make the images visible in the editor, in RTF, the formats currently available in the RichEdit control will be used: + \wmetafile8 \emfblip \pngblip or \jpegblip + If we insert the image programmatically, the format defined by configuration will be used: + + ImgFormatInsideRTF: (ifWmetafile8, ifAccordingImage ) + + The first option (ifWmetafile8) will be the only one offered on systems with an older version of RichEdit (<= 4 ), in which + all images are embedded in RTF with the format \wmetafile8. + With the ifAccordingImage option, the application will use jpegblip for JPG images, emfblip for images that come from EMF *files*, + wmetafile8 for those that come from WMF *files*, and pngblip for the rest: PNG, GIF, TIF, BMP and ICO. + + + * Option: ImgMaxAutoWidthGoal + When inserting an image, the initial visible size will depend on the value set in the ImgMaxAutoWidthGoal property + + 0 It will be shown with its actual size + -1 Will be displayed with a maximum width equal to the visible width of the editor at the time of insertion + >0 A maximum width equal to the indicated one will be displayed (in pixels) + + Of course, once inserted, the image can be resized. This property has no effect on existing, already dimensioned instances + + * At any time it's possible to easily restore the proportions of one or all the images in a node/note and at the same + time reapply the option ImgMaxAutoWidthGoal : + + - Alt+Click on Image toolbutton + It is applied to all the images of the active editor, or only on the selection, if any. + + - "Restore image[s] proportions" to the RTF context menu + This action will reset proportions and reconsider "Max.auto width" on selected image[s]. + If there is no selection, it will modify all images in the editor. + (As requested here: https://github.com/dpradov/keynote-nf/issues/623#issuecomment-1830661325) + + Note: + - The resizing done with Alt-click, when it is applied to all images in the Editor + (with no selection) is temporary by default: if the node has no modifications, its status will + not change, it will continue to remain unmodified and these changes will not will be saved. + But if you want to keep them, just make any minimal change to the node (such as adding or + removing a space...), to mark the node (or note) as modified. + But when applied to a selection, the changes will mark the node (or note) as modified. In this + case, the changes in the images can be reverted with Undo operation. + - The new action, "Restore image[s] proportions", by the opposite, will always mark the node/note + as modified, even when applied to all images in the editor. Changes can also be reverted with + Undo operation. + + + * Options: ImgDefaultLinkMode, ImgLinkRelativePath + Images can be incorporated as a 'copy', adding to the defined storage (or storages): 'owned'. + But they can also be added in Link mode (not owned), in which case only the file path is registered as a reference, its content + is not stored nor is the file deleted if all references to it are removed. + - ImgDefaultLinkMode + 0: Owned by KNT file. Added to one storage. Can be deleted when unused + 1: Linked. Image is independent. It is obtained from its original path and will never be deleted by KNT + + * Option: ImgUseRecycleBin + Allows you to move deleted image files to a subfolder '_RecycleBin' within the Folder mode folder, or to a Zip file located next + to the main one, and called "...Deleted.zip" + + + * Option: ImgSaveInSubfolders + Allows to decide whether or not to save images in subfolders + False by default. If True: in external storage, save files in subfolders, using the name of the note where the image is first added + (As requested in https://github.com/dpradov/keynote-nf/issues/623#issuecomment-1821957039) + + + * Option: ImgKeepOrigName + If checked "Keep original file name", a file named 'MyImage.jpg' will be saved (if possible) with that same name and will not be + prefixed with the ID (such as 10_MyImage.jpg) + + If the image is added by drag and drop, a new input field will be available that will display and allow you to modify the name + with which the file will be saved. If the application detects that no image with the same name is registered, it will preload + the original file name. Otherwise, it will show a label warning of the name conflict and will preload that field with an + alternative name, adding a suffix, which can be changed before accepting the insertion: 'MyImage.jpg' -> 'MyImage_2.jpg' or 'MyImage_3.jpg' ... + The application must review any new name modified by the user, ensuring that it does not collide with any other image. + + When using File | Insert Picture..., and a file with the same name already exists, the modal window used when dropping a file + will be offered, to show the proposed new file name. + + If several images are dragged and there are some file/s with a name used, a label will be shown giving a warning. + If continue inserting, that files will be automatically renamed. + + * Option: ImgSingleViewerInstance + When ImgSingleViewerInstance = True [default], each image is shown in the same visible Viewer, if any, + and the Viewer window's size is maintained, trying to show images at 100%, adapting to that size. + If ImgSingleViewerInstance = False, it is possible to show several images simultaneously, + resizing each window to try to show its image at 100% + + * Option: ImgHotTrackViewer + When ImgSingleViewerInstance = True and ImgHotTrackViewer is set, if the viewer is open, selecting or clicking + in any image (or image link) will show the image in the viewer, maintaining the focus on the editor. + Added a button in Viewer that lets makes it always visible (by default it will on) + + * Option: ImgViewerPath (only ini option) + Allows to enter an absolute or relative (to keynote.exe) path to an external image viewer + As requested in https://github.com/dpradov/keynote-nf/issues/623#issuecomment-1824929978 + + + + - A record of added and deleted images is kept in external storage through a LOG FILE. + + + - Related to the possibility of showing or hiding IMAGES, the application will maintain in memory, as content (stream) associated + with each node, the version without images, in which its content is hidden and a link is included in its place. + The content of the nodes/notes will only be 'expanded' with the content of the images within the RTF (\pict tag) in the notes + and the selected nodes (visible), and only if the images are being shown (View | Show Images) + + This same format is used when saving: NOTES / NODES DO NOT SAVE THE CONTENT OF THE IMAGES BUT A REFERENCE to them. + This speeds up opening and saving and reduces the size of the KNT file, especially if images are saved only on external storage. + But even if they are saved as Embedded KNT, the size will also be reduced very noticeably because RTF images, even using the + pngblip and jpegblip formats, take up more than twice as much space in ASCII + Hexadecimal as they do directly in binary. + + + - The content of the images is recovered and kept in memory. In the case of external images (linked or not), the content is kept in + memory for a set of minutes since the last access (to view it). After this time without being accessed, the content of the image + is released from memory. + * If at the time of verification, the application detects that the storage is not available, the content of these images + will not be released. + + + + Registration in KNT of the information associated with each image. Serialization/deserialization + --------------------------- + - In the case of using a storage mode other than Embedded RTF, the application will use an EXTENDED KNT FORMAT when saving in + which new blocks have been incorporated at the end of the file, to allow including the registration of stores and images. Ex: + + + %S + SM=2 + SD=1|TestIMG_img + %I + II=5 + PD=1|NOTE1\|1_Image 24oct.png|1|32|32|343790583||1|6||0 + PD=2|NOTE2\|2_Image 24oct.jpg|1|770|649|1481786765||1|3|CORONA|0 + PD=3|NOTE2\|3_sample.wmf|5|770|649|1976212572|E:\sample.wmf|1|2||0 + PD=4|||1|120|171|1006143828|E:\Cocobill_avatar.png|0|2||0 + %EI + EI=1|1_Image 24oct.png| + <--image in binary--> + ##END_IMAGE## + EI=|| + <--image in binary--> + ##END_IMAGE## + ... + %% + + %S: Storage section + SM= Reflects the storage mode.. 0:EmbeddedRTF 1:EmbeddedKNT 2:External 3:ExternalAndEmbeddedKNT + (Mode 0 will not actually be displayed, since in that case these new blocks will not be used...) + + SD= Type(0:Zip 1:Folder)|Path + (Only included with modes 2 and 3) + + %I: Image section. Lists information about the images used in the KNT file: + + II= Shows the ID to be used for the following image + PD= IDImg|Path|Name|Format|Width|Height|crc32|OriginalPath|Owned|RefCount|Caption|MustBeSavedExt + - IDImg: Each image has a unique numerical ID (>=1) + - Path: Relative path to storage, this will normally correspond to the name of an existing note + - Name: Unique name of the file within the storage. + - Format: 0:GIF, 1:PNG, 2:JPG, 3:BMP, 4:TIF, 5:WMF, 6:EMF + - Width, Height: Width and height of the image. Each instance may be using different values. + - crc32: Value obtained from the image content. Used to identify if an added image is new or is another instance + of one already registered. + - Original path: Obtained in the case of insertion from existing files + - Owned: 1:Owned by KNT file. Added to one storage. Can be deleted when unused + 0:Linked. Image is independent. The image is obtained from its original path and neve will be deleted by KNT + - ReferenceCount: Number of instances of the image within the KNT file. + When the number of references becomes 0, the image will be deleted (when saving changes) from the %I block + and the %EI block (the latter if the External or ExternalAndEmbKNT modes are used). + In the case of using the External or ExternalAndEmbKNT modes (the image being 'owned'), the corresponding + file will be deleted from the external storage. + A line in KNT with this field set to 0 indicates that the image has been deleted but is missing from external + storage, not accessible at the time of saving the KNT file. + + - Caption: Image title + - MustBeSavedExt: 1: Indicates that the image is waiting to be saved to its external storage. + Its content will be found in the %EI block + + %EI: Embedded Images + In the case of using smEmbKNT or smExternalAndEmbKNT (fStorageMode: TImagesStorageMode) as storage mode + The content of each image (except linked ones) will be saved within this block + + + + +================================================================================================================ + + +//--------------------------------------------------------------------- +// TFilesStorage +//--------------------------------------------------------------------- + TFilesStorage: + Manages the saving of image files from a specific storage + There will be various storage types, depending on TStorageType = (stZIP, stFolder, stEmbeddedKNT, stEmbeddedRTF), + implemented by the corresponding classes: + TZipStorage, TFolderStorage, TEmbeddedKNTStorage + + Images will be saved in storages of different types: + - stZIP: ZIP compressed files + - stFolder: In folders and subfolders in a file system + - EmbeddedRTF: Equivalent to the usual placement of images: within the RTF content itself, as hexadecimal saved in ASCII. + - EmbeddedKNT: Images located at the end of the KNT file, in binary + + It is possible to use at the same time, in a KNT file, an external storage (ZIP or folder) with the internal EmbeddedKNT + + TStorageType = (stZIP, stFolder, stEmbeddedKNT, stEmbeddedRTF); + + + +//--------------------------------------------------------------------- +// TKntImage +//--------------------------------------------------------------------- + + When image management is done (ImagesManger.StorageMode <> smEmbRTF) the ImagesManager object will have a list of images (TKntImage) + where the attributes required for management are recorded, such as an ID, the location within the storage or the height and width of + the image, for example. + + There can be multiple instances of the same image, in any note/node. This will not result in any increase in file size since the + image will only be saved once. The only thing that is maintained for each instance is the visible width and height, within a hyperlink. + All image data is saved in TKntImage objects. Only the attributes of each instance, the visible height and width, will be saved in the + RTF content itself. + + When a new instance is created, the number of references of the associated image will increase, and will decrease when it is deleted. + Something similar to how the "String" type works in Delphi. + + If at the time of saving the file an image has 0 references, it can be deleted if: + - This is an image that belongs to the KNT (owned) file, not Linked + - In case of external storage, if it is available + +//--------------------------------------------------------------------- +// TImageManager +//--------------------------------------------------------------------- + + It takes care of all image management, also including mechanisms to allow image insertion, even for the 'classic' storage mode, Embedded RTF. + + + * Image visibility + ------------------------ + + The instances or uses of the different images may be in one of the following two states: TImagesMode = (imImage, imLink) + + - 1. imImage + ----------- + It is the equivalent of the current situation of an image, where it is visible and its content is embedded in the RTF. + Ex: {\pict{\*\picprop}\wmetafile8\picw3888\pich5185\picwgoal2204\pichgoal2940 0100090000038c0000000000760000....} + + We will not include the image ID inside the \pict tag (we cannot use tags like \bliptab and \blipuid, because they are ignored), + but we can do it right next to it with a hidden field, similar to the one used with the recent internal links: + + \v\'11I\'12\v0{\pict{\*\picprop}\wmetafile8\picw3888\pich5185\picwgoal2204\pichgoal2940 0100090000038c0000000000760000....} + + + - 2. imlink + -------------- + It corresponds to the image in a state in which it does not include the content but only information that identifies the image itself (an ID) + and other information specific to the instance: visible width and height. + It is based on the use of RTF hyperlinks that include a link with a specific format (analogous to what is already done with KN's internal + links, also its own), preceded by a hidden label located to the left of the hyperlink: + + \v\'11I\'12\v0{\field{\*\fldinst{HYPERLINK "img:ImgID,WGoal,HGoal"}}{\fldrslt{\ul\cf1 Caption}}} + + - "Caption" will show the title of the image, if it has one, and if not, the name of the file (if the image has been obtained from a file) + or a string constructed at the time of registering the image. + - "img:ImgID,WGoal,HGoal". Image ID along with the visible width and height of the instance + + It is the format used to save images (in storage modes <> smEmbRTF). If the storage mode is smExternal, the size of the KNT file will be + significantly reduced because it will not contain the content of any image, only a list with the list of registered images. + + The application allows you to change the visibility of all the images in the file (which becomes effective only when the note/node is + required to be shown). If the option to hide the images is selected, the application displays them in this imLink format, hiding their + content and instead offering a link from which you can consult and edit their title. + + + * Using hidden tags, monitoring actions + ---------------------------------------- + The application monitors all actions that could result in image insertions or deletions. To do this, it processes the content pasted from + the clipboard looking for the presence of images and analyzes RTF content in search of RTF tags associated with the existence of images. + It makes use of its own, hidden labels, analogous to those already used to maintain the reference to the destination in recent bookmarks. + These labels contain only the ID of the image and are placed to the left of them, whether they are in their visible (imImage) or 'hidden' + (imLink) mode. This processing is optimized and does not affect the normal operation of the application at all. + + The use of these tags (e.g. "\v\'11I3\'12\v0") simplifies the identification of already registered images. But since they cannot be added + 'inside' the image tags themselves, it is the application's responsibility to ensure that they are always kept next to the image they accompany. + + To do this, for example, when content is inserted on the editor, it is ensured that, if it acts on an image, it is also done on its associated + hidden tag, extending the selection to include it. When an image is deleted (with DELETE/DELETE or BACKPSPACE, or by cutting to the clipboard) + it is controlled whether to also delete its label, etc. + + Copying an individual image to the clipboard does not also send the tag, to ensure that the content is served as an image and not just RTF + content. But the copied ID is noted, in case it is detected that this copied content is then pasted into the KNT itself. + + * It has been used to optimize the method that allows us to discriminate whether the current content on the clipboard has been copied by this + instance of the KNT application or another application. This was necessary, for example, to determine whether to paste the content as + Plain Text or not, depending on the corresponding configuration. + + * Eliminations + -------------- + Image deletions (TKntImage) are processed on save. They could be done immediately but would have the problem that it would not allow the UNDO + mechanism that the RichEdit control offers. + + * Image IDs + ---------------- + Each image has a unique ID within the KNT file, whether it is Linked or not. When the KNT file is saved to disk, the number of the next ID + that can be used is recorded. This number is determined from the ID of the last saved image. To do this, a distinction is made between + NextImageID and NextTempImageID. Images that are added but removed before saving the file do not 'consume' ID. + + + * Image insertions by code + ----------------------- + When inserting an image by code, instead of using the clipboard, as has been done until now, it is necessary to generate all the image + information necessary to construct the RTF sentence that the RichEdit control expects. + + Note. Insert->Picture has been adding them through the clipboard, but that causes them to be saved in WMF format (wmetafile8). + See my notes for Release 1.8.0 Beta 6 + We must avoid using the clipboard for this, and instead insert a string with the necessary RTF command. + EYE. What I indicated in the Release is true when dragging on the editor in KeyNote. But if it is done on a file opened with WordPad, + it is always created as wmetafile8, and even doing so loses quality (it seems to handle fewer colors). Furthermore, if you try to open + a file with a format other than wmetafile8 from WordPad, it gives a security notice after which, depending on whether it is accepted + or not, it will display the content. In this link they explain the reason: + https://forums.malwarebytes.com/topic/259359-wordpad-ms-word-security-warning-on-images/ + diff --git a/general/kn_Const.pas b/general/kn_Const.pas index 37275c9..560d42c 100644 --- a/general/kn_Const.pas +++ b/general/kn_Const.pas @@ -110,9 +110,9 @@ procedure DefineConst; const Program_Name = 'KeyNote NF'; - Program_Version = '1.8.1 Beta 5'; - Program_Version_Number = '1.8.1.5'; - Program_Version_Date = '02/12/2023'; + Program_Version = '1.8.1 Beta 6'; + Program_Version_Number = '1.8.1.6'; + Program_Version_Date = '09/12/2023'; Program_License = 'Free software, Open Source (Mozilla Public License 2.0)'; Program_URL = 'https://github.com/dpradov/keynote-nf'; //'http://keynote.prv.pl'; diff --git a/general/kn_INI.pas b/general/kn_INI.pas index a6b6e23..67c0c39 100644 --- a/general/kn_INI.pas +++ b/general/kn_INI.pas @@ -1117,7 +1117,7 @@ procedure InitializeTabOptions( var Struct : TTabOptions ); InactiveColor := _GF_CLWINDOW;; with Font do begin - FSize := 8; + FSize := 9; FColor := clWindowText; FName := 'Tahoma'; FCharset := DEFAULT_CHARSET; diff --git a/keynote.dproj b/keynote.dproj index 1517ec8..9469957 100644 --- a/keynote.dproj +++ b/keynote.dproj @@ -120,8 +120,8 @@ gdiScaling 8 1 - 5 - CompanyName=;FileDescription=KeyNote NF 1.8.1 Beta 5;FileVersion=1.8.1.5;InternalName=;LegalCopyright=(c) Daniel Prado 2007-23 (c) Marek Jedlinski 2000-05;LegalTrademarks=Free software, MPL 2.0;OriginalFilename=keynote.exe;ProductName=KeyNote NF (New Features);ProductVersion=1.8.1.5;Comments=;ProgramID= + 6 + CompanyName=;FileDescription=KeyNote NF 1.8.1 Beta 6;FileVersion=1.8.1.6;InternalName=;LegalCopyright=(c) Daniel Prado 2007-23 (c) Marek Jedlinski 2000-05;LegalTrademarks=Free software, MPL 2.0;OriginalFilename=keynote.exe;ProductName=KeyNote NF (New Features);ProductVersion=1.8.1.6;Comments=;ProgramID= VCL;$(DCC_Define) @@ -138,8 +138,8 @@ gdiScaling 8 1 - 5 - CompanyName=;FileDescription=KeyNote NF 1.8.1 Beta 5;FileVersion=1.8.1.5;InternalName=;LegalCopyright=(c) Daniel Prado 2007-23 (c) Marek Jedlinski 2000-05;LegalTrademarks=Free software, MPL 2.0;OriginalFilename=keynote.exe;ProductName=KeyNote NF (New Features);ProductVersion=1.8.1.5;Comments=;ProgramID= + 6 + CompanyName=;FileDescription=KeyNote NF 1.8.1 Beta 6;FileVersion=1.8.1.6;InternalName=;LegalCopyright=(c) Daniel Prado 2007-23 (c) Marek Jedlinski 2000-05;LegalTrademarks=Free software, MPL 2.0;OriginalFilename=keynote.exe;ProductName=KeyNote NF (New Features);ProductVersion=1.8.1.6;Comments=;ProgramID= VCL;$(DCC_Define) true keynote_Icon.ico @@ -148,7 +148,7 @@ 2 true true - -debug1 + Profiles\F9\keynote.ini diff --git a/keynote.res b/keynote.res index 82535df..9911ffc 100644 Binary files a/keynote.res and b/keynote.res differ diff --git a/kn_Main.pas b/kn_Main.pas index 93d8b0a..f49d0d3 100644 --- a/kn_Main.pas +++ b/kn_Main.pas @@ -15,7 +15,7 @@ *****************************************************************************) -{$DEFINE DEBUG_IMG} +{.$DEFINE DEBUG_IMG} interface @@ -1507,8 +1507,7 @@ implementation STR_80= 'Unexpected error.'; STR_81= 'Could not open KeyNote file "%s"'; STR_82= 'This command will start your browser and direct it to KeyNote NF website, where ' + - 'you can download the latest version of the program, read the FAQ, submit bug reports or feature requests with the Issue Manager. ' + #13+#13+ - 'There is also a discussion mailing list where you can post questions and discuss about the program.' + #13+#13 + 'Continue?'; + 'you can download the latest version of the program, read the FAQ, submit bug reports or feature requests with the Issue Manager. ' + #13+#13+ 'Continue?'; STR_82B= 'Save tree structure to file'; STR_83= 'Hide &Resource Panel'; STR_84= 'Show &Resource Panel'; diff --git a/resources/Colors.bmp b/resources/Colors.bmp new file mode 100644 index 0000000..2d55eb9 Binary files /dev/null and b/resources/Colors.bmp differ diff --git a/resources/ColorsBG.bmp b/resources/ColorsBG.bmp new file mode 100644 index 0000000..ef844e1 Binary files /dev/null and b/resources/ColorsBG.bmp differ