-
Notifications
You must be signed in to change notification settings - Fork 57
/
Images_Readme.txt
572 lines (423 loc) · 36.9 KB
/
Images_Readme.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
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|<size>
<--image in binary-->
##END_IMAGE##
EI=<IDImage>|<FileName>|<size>
<--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<IMG>\'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<ImgID>\'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/