[ark] [Bug 431348] New: rar files with a unicode name containing non-latin characters cannot be opened
https://bugs.kde.org/show_bug.cgi?id=431348 Bug ID: 431348 Summary: rar files with a unicode name containing non-latin characters cannot be opened Product: ark Version: 20.12.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: plugins Assignee: rthoms...@gmail.com Reporter: nevinevi...@yahoo.com CC: elvis.angelac...@kde.org Target Milestone: --- SUMMARY If a .rar filename contains non-latin characters (e.g. Japanese), Ark will not be able to open the file's contents. STEPS TO REPRODUCE 1. Have a .rar file with a Japanese name (or other language with a non-latin character set) 2. Try opening it with ark OBSERVED RESULT Error: "The archive is empty or Ark could not open its content" Additional comment pops up: Cannot open /home/user/Downloads/??? ? ? .ra No such file or directory EXPECTED RESULT Files should be able to be opened regardless of their name, if allowed by the OS. Furthermore, other file formats (zip, 7z, etc) don't have this problem. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux 5.10.4-1-default (available in About System) KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.77.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION Renaming the file to a name containing only latin characters allows Ark to open its contents. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 431348] rar files with a unicode name containing non-latin characters cannot be opened
https://bugs.kde.org/show_bug.cgi?id=431348 --- Comment #2 from Neviril --- Created attachment 134689 --> https://bugs.kde.org/attachment.cgi?id=134689&action=edit Filename example affected by the bug -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 431348] rar files with a unicode name containing non-latin characters cannot be opened
https://bugs.kde.org/show_bug.cgi?id=431348 --- Comment #3 from Neviril --- It appears to be the "RAR Plugin". I have attached a test file. It's a random RAR archive retrieved from the internet containing a small binary file. Contents are irrelevant (the file was actually randomly picked form the internet as I couldn't find a quick way for creating RAR archives with my Linux distribution). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 407498] New: Color profiles should take into account monitor model and serial number
https://bugs.kde.org/show_bug.cgi?id=407498 Bug ID: 407498 Summary: Color profiles should take into account monitor model and serial number Product: krita Version: nightly build (please specify the git hash!) Platform: MS Windows OS: MS Windows Status: REPORTED Severity: wishlist Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: nevinevi...@yahoo.com Target Milestone: --- SUMMARY A discussion on #Krita on IRC relatively to a bug in the color profile->display association revealed a larger background problem of associating a color profile to a "screen number". Screen numbers are not fixed: they can change depending on which is the primary display, number of displays connected and what display outputs are enabled on the graphics card at any given time. On the other hand, monitor model and serial number are fixed. It's important to take into account some sort of unique identifier, as the calibration (and associated color profile) of two or more physically identical displays will likely not be identical, as personal experience also revealed after coming across identical displays with noticeably different factory colors even with the same display settings from the OSD. The Krita developer involved in the discussion pointed out that there doesn't seem to be a way of getting the screenNumber of a QScreen, that QDesktopWidget is also pretty much obsolete and doesn't really work well under high dpi, and that some broken displays might not not have the proper serial number in their EDID info. SOFTWARE/OS VERSIONS Windows: Windows 10 64-bit 1809 ADDITIONAL INFORMATION Information valid as of the latest nightly build from Jenkins at the time of writing (git 1f648b3). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 408133] New: Brush strokes terminate slowly after a prolonged drawing session
https://bugs.kde.org/show_bug.cgi?id=408133 Bug ID: 408133 Summary: Brush strokes terminate slowly after a prolonged drawing session Product: krita Version: git master Platform: MS Windows OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: OpenGL Canvas Assignee: krita-bugs-n...@kde.org Reporter: nevinevi...@yahoo.com Target Milestone: --- === SUMMARY === After a period of prolonged drawing / sketching, brush strokes appear to increasingly become laggier when the pen is lifted from the canvas. In other words, brush strokes get completed (drawn on screen) slowly when this happens. It is important to point out that this does not happen while the pen is down drawing. This is more easily observed by drawing with a large amount of small brush strokes as it might be common in sketching activity with pen-like brushes, like Ink-2-Fineliner. Under this scenario the issue can be reproduced in as low as 5-10 minutes, which can be compared to similar reports mentioning periods of hours. The issue has initially a small magnitude, but as the drawing session goes on it appears to increase over time (become more noticeable) up to a point where it even gets difficult to accurately control where small strokes end. At that point restarting Krita appears to be the only option left to make the program behave normally. What occurs in summary is a progressively increasing loss of pen responsivity or "feel". This has been observed with the OpenGL renderer. Switching to "Direct3D 11 via ANGLE" does not seem to help: the issue occurs with it too. Related reported for example on Reddit by others exist. The first thread listed below contains video evidence of an issue which looks similar to what I have been experiencing: - https://www.reddit.com/r/krita/comments/buh2gs/brush_lag_after_using_krita_for_a_while_krita_42/ - https://www.reddit.com/r/krita/comments/bukewh/i_experience_lags_with_quicklong_brush_strokes/ == STEPS TO REPRODUCE == 1. Choose a small brush 2. Start drawing with fast repetitive motions 3. Over time (or after more brush strokes are made), brush strokes will start getting completed slowly when the pen is lifted SOFTWARE/OS VERSIONS Windows 10 64bit 1903 AMD Radeon Software 19.5.2 == ADDITIONAL INFORMATION == Observed occurring on: - Krita 4.2.0 - Krita 4.3.0 git 4ddc08e Does not appear to occur on: - Krita 4.1.7 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 408133] Brush strokes terminate slowly after a prolonged drawing session
https://bugs.kde.org/show_bug.cgi?id=408133 --- Comment #2 from Neviril --- If it can be of any help, I always use "None" brush smoothing in tool option (rationale: under Windows 10 the Wacom pen tablet driver already performs significant stroke smoothing compared to the Linux driver). It could still be something related with pen tablet handling though, as the issue appears to occurs more easily after drawing many short and fast brush strokes in quick succession. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 408133] Brush strokes terminate slowly after a prolonged drawing session
https://bugs.kde.org/show_bug.cgi?id=408133 --- Comment #11 from Neviril --- Just finished testing 4.3.0-prealpha (git 71af6ec) on Windows 10-64bit 1903 with a drawing session composed of mainly fast brush strokes. The latest build does *not* solve the problem for me. After a while (in the order of minutes) I observe the same issue I initially reported and brush strokes over time get increasingly slowly terminated when the pen is lifted. Closing and reopening the image, even without closing the entire Krita application, appears to temporarily solve the issue, as others have pointed out. However selecting a different renderer (ANGLE instead of OpenGL) while the program is active (i.e. without restarting it) does not seem to solve it for me. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 408133] Brush strokes terminate slowly after a prolonged drawing session
https://bugs.kde.org/show_bug.cgi?id=408133 --- Comment #25 from Neviril --- After testing Dmitry's build for a while I'm confident that the latest changes solved the issue I initially reported. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 408427] New: Reference images are not supposed to have boolean operations applied to them
https://bugs.kde.org/show_bug.cgi?id=408427 Bug ID: 408427 Summary: Reference images are not supposed to have boolean operations applied to them Product: krita Version: git master Platform: MS Windows OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: Tools/Reference Images Assignee: krita-bugs-n...@kde.org Reporter: nevinevi...@yahoo.com Target Milestone: --- (4.3.0-prealpha git 81fdaf7) SUMMARY When a reference image is right-clicked as soon as the reference image tool is enabled, additional options related with vector handling appear. STEPS TO REPRODUCE 1. Add any reference image to the canvas 2. Select another tool (e.g. the Brush tool) 3. Select again the reference image tool 4. Right click on a reference image OBSERVED RESULT More right-click options than usual appear. EXPECTED RESULT I understand from discussions on #Krita on IRC that the vector boolean operation menu is not supposed to appear at all with reference images. SOFTWARE/OS VERSIONS Windows 10 64bit 1903 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 408453] There appears to be no mechanism to change menu text size (my vision is restricted)
https://bugs.kde.org/show_bug.cgi?id=408453 Neviril changed: What|Removed |Added CC||nevinevi...@yahoo.com --- Comment #1 from Neviril --- I think this is supposed to be up to the window manager. On KDE Plasma there are separate settings for Qt and GTK applications. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 397320] New: [Wish] No obvious way to probe the dirty/modified flag of the active document
https://bugs.kde.org/show_bug.cgi?id=397320 Bug ID: 397320 Summary: [Wish] No obvious way to probe the dirty/modified flag of the active document Product: krita Version: nightly build (please specify the git hash!) Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: Scripting Assignee: krita-bugs-n...@kde.org Reporter: nevinevi...@yahoo.com Target Milestone: --- I've been advised to open a wishbug for this. I am in the process of writing simple Python plugin. In short, I have a docker with two buttons for iterating back/forth through files from a given directory, replacing the open document with a new one. This operation implies that if the active document has unsaved changes they will be irreversibly lost. A possibility could be to always save the open file before switching it, but in this way iterating through the existing file list becomes much slower. Unnecessarily modifying files is generally not desirable on reliability and performance grounds. Therefore it would be useful to check out in advance if the active document has any unsaved changes. Oddly enough, I couldn't find any obviously named class member in the Krita Python API documentation for checking the modified/dirty status of a document, like for example something like isDirty(), or isModified(), etc. According to one developer on the official #Krita IRC channel, this doesn't seem to be currently possible. An alternative could be making Document::save() operate in a way that it doesn't actually save the document if no changes are detected, but it could be a potentially breaking change, and being able to save the document despite not having actually modified it could potentially have uses for some people. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 386767] [Multithreaded brushes] Add preference for adjusting maximum update period
https://bugs.kde.org/show_bug.cgi?id=386767 Neviril changed: What|Removed |Added CC||nevinevi...@yahoo.com --- Comment #2 from Neviril --- In an earlier bug report I noted that the effective update rate currently (with the multithreaded brush system in place) appears to be significantly lower than the value set up in user settings. This could be related to the perceived feeling of worse performance reported here. https://bugs.kde.org/show_bug.cgi?id=386620 In a test I tried extending the maximum fps value allowable in the settings, and that seemed to help, but this is just a workaround that doesn't solve the underlying issue(s) with the painting framerate. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 398771] New: EPub backend: changing default font size doesn't update the page number
https://bugs.kde.org/show_bug.cgi?id=398771 Bug ID: 398771 Summary: EPub backend: changing default font size doesn't update the page number Product: okular Version: 1.5.1 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: EPub backend Assignee: okular-de...@kde.org Reporter: nevinevi...@yahoo.com Target Milestone: --- =Background information= Often, I need to read EPub ebooks a few meters away from my monitor and it is helpful for this to increase the default font size and type (on my configuration by default it's "Noto Sans, 10") to make text more easily readable. =Issue encountered= I found that changing the font size and type in EPub backend options results in Okular not updating the page number. Practically speaking, if an EPub Ebook has a 200 page count and I increase the font size, text appears to be reflowed correctly, but the page count would still remain 200. The most immediate issue is that the book gets clipped, meaning that the end could not be read if not by decreasing font size again. Conversely, when decreasing the font size, blank pages result at the end of the document, although this is more than an annoyance than a usage-breaking bug. =Additional notes= Closing/reopening Okular and/or the document does not seem to solve the issue. I observed this issue with different EPub documents. =Backend information= Version 0.2.3 KDE Frameworks 5.49.0 Qt 5.11.1 (built against 5.11.1) The xcb windowing system -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 385978] New: Unable to Ctrl+Scrollwheel zoom swatches in palette docker when docker width is < 220px
https://bugs.kde.org/show_bug.cgi?id=385978 Bug ID: 385978 Summary: Unable to Ctrl+Scrollwheel zoom swatches in palette docker when docker width is < 220px Product: krita Version: 3.3.1 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: minor Priority: NOR Component: Dockers Assignee: krita-bugs-n...@kde.org Reporter: nevinevi...@yahoo.com Target Milestone: --- The Krita documentation (https://docs.krita.org/Palette) states: "If you find the size of color swatches too small, you can increase the size by hovering your mouse over the palette and scrolling while holding Ctrl" However, as of Krita 3.3.1 (Windows 10 64bit 1709) this doesn't appear to be possible when the Palette docker width is less than a certain size (determined to be roughly 220px on this configuration). As soon as the width of the docker is increased above this threshold, the shortcut starts working again. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 385978] Unable to Ctrl+Scrollwheel zoom swatches in palette docker when docker width is < 220px
https://bugs.kde.org/show_bug.cgi?id=385978
--- Comment #2 from Neviril ---
Quick and dirty workaround.
In /libs/ui/kis_palette_view.cpp
In KisPaletteView::wheelEvent
There is this check:
...
if ( setSize >= 12 ) {
...
Reducing the value setSize is checked against to a lower value (e.g. 1,
although this is probably too small) appears to resolve this bug.
The main issue here is that all scroll wheel events are blocked, but it would
be useful if scrolling up (e.g. increasing swatch size) was still allowed.
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 385978] Unable to Ctrl+Scrollwheel zoom swatches in palette docker when docker width is < 220px
https://bugs.kde.org/show_bug.cgi?id=385978
--- Comment #3 from Neviril ---
This modification makes it working as intended and solves an inconsistency in
the UI (decreasing docker width to the minimum size sets swatch size to 8px,
but this swatch size cannot be normally set while scroll-zooming):
if ( (event->delta() <= 0) && (setSize <= 8) ) {
// Ignore scroll-zooming down below a certain size
} else {
horizontalHeader()->setDefaultSectionSize(setSize);
verticalHeader()->setDefaultSectionSize(setSize);
KisConfig cfg;
cfg.setPaletteDockerPaletteViewSectionSize(setSize);
}
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 385978] Unable to Ctrl+Scrollwheel zoom swatches in palette docker when docker width is < 220px
https://bugs.kde.org/show_bug.cgi?id=385978 --- Comment #5 from Neviril --- Created attachment 108469 --> https://bugs.kde.org/attachment.cgi?id=108469&action=edit Palette Docker scrolling patch This patch solves an inconsistency in the UI where the user is unable to scrollwheel-zoom-in color swatches in the palette docker after the same has been reduced to its minimum width, which causes color swatch size to be set to 8px, a size that cannot be normally set with the ctrl+scrollwheel shortcut. This color swatch size is now made accessible with the scroll wheel, and scroll events are now blocked only when trying to further zoom out. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 380437] Save does not work when I only change layer name
https://bugs.kde.org/show_bug.cgi?id=380437 Neviril changed: What|Removed |Added CC||nevinevi...@yahoo.com --- Comment #3 from Neviril --- It might go slightly deeper than this. I noticed that not only these actions don't "dirty" an image, but they also are not undoable: - Layer name (renaming by double clicking or F2 key) >From the right-click context menu on the layer boxes: - Layer color - Isolate layer - Show in timeline Setting layer color and name with the Layer Properties dialog (F3 key) however does "dirty" the image and is an undoable action. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 386019] New: Brushes displayed in brush editor may have a lower quality than strokes actually painted on the canvas
https://bugs.kde.org/show_bug.cgi?id=386019 Bug ID: 386019 Summary: Brushes displayed in brush editor may have a lower quality than strokes actually painted on the canvas Product: krita Version: git master Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: nevinevi...@yahoo.com Target Milestone: --- Created attachment 108485 --> https://bugs.kde.org/attachment.cgi?id=108485&action=edit Screenshot showing the difference in line quality in Krita 3.3.1 This has been tested both with 3.3.1 and git master on Windows 10 64bit 1709. In the brush "Scratchpad" in the Brush settings editor in Krita 3.3.1 (as well as git master) I noticed that line quality is often lower than on the actual canvas. I suspect that brush strokes in the brush editor always have 8 bit per channel color precision, while the canvas they can have a higher bit depth. Bit depths of 16 bit per channel can noticeably increase hard line quality/antialiasing compared to 8 bit per channel mode, but this isn't taken advantage of by the brush editor. This isn't just cosmetic. There are implications on usability in that creating new brushes might take longer than assumed due to this difference (and subsequent required testing on the canvas). I have attached a screenshot showing this issue with strokes painted with the same brush. The canvas has a 16 bit integer/channel depth. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 386620] New: Canvas framerate limiter might not be working as intended
https://bugs.kde.org/show_bug.cgi?id=386620 Bug ID: 386620 Summary: Canvas framerate limiter might not be working as intended Product: krita Version: 4.0 pre-alpha Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: OpenGL Canvas Assignee: krita-bugs-n...@kde.org Reporter: nevinevi...@yahoo.com Target Milestone: --- Krita 4.0 pre-alpha (git 86851fa) exposes to the user a frame limiting function under "Settings > Configure Krita > Performance > Advanced > Limit Frames per Second while painting". After fiddling around with it for a while, trying different settings (making sure to restart the program to apply the new values), I came to the conclusion that the frame limiting function might not be working as intended, producing as a result an *effective* canvas update framerate that is roughly (slightly more than) half the user set value. ==How to observe it?== 1) Try setting a low frame limit value, like for example 20 fps. 2) Reboot Krita. 3) Create a new image and proceed to recording a short video capture of the desktop/program at the frame rate of the display frequency rate (typically 60 Hz) using for example the open source OBS (Open Broadcast Studio) software, and a small brush at 100% canvas zoom in order to avoid any GPU bottleneck issue. 4) The framerate of the canvas in Krita can then be easily analyzed using a standard video player (e.g. VLC) advancing the video frame by frame. ==Results== At a Krita canvas fps of 20 fps, and a video framerate of 60 fps, brush strokes and the brush cursor appear to update roughly every 5 or 6 frames (sometimes 4 or 7). This corresponds to an *effective* canvas frame rate of 10-12 fps, which is significantly lower than the user set value. At a Krita canvas fps of 60 fps (equivalent to the display refresh rate) and again a recording video frame rate of 60 fps, bursh strokes appear to update most of the time 2 frames, less often every frame. In a test, the canvas updated 44 times over the course of 69 frames, implying an actual framerate of about 38 fps. That the canvas updates at a much lower rate than the screen refresh rate is also subjectively noticeable by eye during ordinary program operation. ==System configuration== Windows 10 64bit Fall Creators Update AMD Radeon RX480 with Radeon Software 17.11 Intel i5 3550 4-core GPU. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 374336] New: Incorrect tablet mapping in Krita after disabling or enabling a secondary display
https://bugs.kde.org/show_bug.cgi?id=374336 Bug ID: 374336 Summary: Incorrect tablet mapping in Krita after disabling or enabling a secondary display Product: krita Version: 3.1.0 Platform: Other OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: tablet support Assignee: krita-bugs-n...@kde.org Reporter: nevinevi...@yahoo.com Target Milestone: --- This issue pertains to recent versions of Krita on Windows 10 64bit, using a Wacom Intuos 5 L pen tablet. When a secondary display is enabled or disabled *after Krita has been started*, the pen mapping inside the program gets messed up (= there is no more 1:1 correspondence between the tablet and the cursor position on screen), only to return back to normal either when: 1) The previous display configuration is restored; 2) Krita is restarted. As this only occurs with Krita and not other programs in the same configuration/OS I suspect that this issue has to do with the way pen tablet management inside the program handles display mapping. According to a Krita developer on IRC I consulted with before submitting this bug, when the display configuration changes the [pen tablet] driver sends a special event to all the applications and they should remap their input accordingly. Krita used to process it but probably something changed after porting it to Qt5. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 374336] Incorrect tablet mapping in Krita after disabling or enabling a secondary display
https://bugs.kde.org/show_bug.cgi?id=374336 --- Comment #2 from Neviril --- I understand that this issue may be limited to specific user scenarios and may or may not be directly fixed within the program itself. But as I mentioned on IRC, perhaps if there was a way (e.g. with a key shortcut) to manually reset inside the program the pen tablet mapping, that would be fine as a workaround to avoid closing and restarting Krita whenever a new display is enabled or disabled in the OS. I do not know if there would be performance issues by making this automatically occur when pen proximity goes off/on. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 374493] New: Page orientation does not affect previously selected dimension in New Image dialog
https://bugs.kde.org/show_bug.cgi?id=374493 Bug ID: 374493 Summary: Page orientation does not affect previously selected dimension in New Image dialog Product: krita Version: 3.1.1 Platform: Other OS: MS Windows Status: UNCONFIRMED Severity: minor Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: nevinevi...@yahoo.com Target Milestone: --- =Reproducibility= Always reproducible. =How to reproduce= 1) File > New. The new image creation dialog appears; 2) Click on the Width or Height dimension box to edit it; 3) Click the orientation icons (Vertical|Horizontal) one or more times. =What happens= The selected dimension does not get affected by the page orientation setting and as a result the width and height will become equal (square). =Expected result= The page orientation setting should have an effect even after one of the dimensions has been previously clicked for editing. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 374497] New: Crash when performing any action immediately after Tool Options location is changed to "toolbar"
https://bugs.kde.org/show_bug.cgi?id=374497 Bug ID: 374497 Summary: Crash when performing any action immediately after Tool Options location is changed to "toolbar" Product: krita Version: 3.1.1 Platform: Other OS: MS Windows Status: UNCONFIRMED Severity: crash Priority: NOR Component: general Assignee: krita-bugs-n...@kde.org Reporter: nevinevi...@yahoo.com Target Milestone: --- A prerequisite for this bug is that Tool Option location is in the docker and that there is an open file. =Reproducibility= I have tested it three consecutive times without fail. =How to reproduce= 1) Have the Tool Options docker visible; 2) "Configure Krita" > General > Tools > Tool Options Location > In Toolbar; 3) Press OK; 4) Choose any tool that will change the content of the Tool Options docker. I first encountered the bug by pressing "V" to engage the straight line tool) or perform any action that will do the same. =Result= Krita will crash. Any unsaved result will be lost unless an autosave is available. =Expected result= The dialog window that allows to change the Tool Options location states that Krita needs a restart after the operation. This appears to suggest that doing so is not strictly necessary to keep using the program. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 374497] Crash when performing any action immediately after Tool Options location is changed to "toolbar"
https://bugs.kde.org/show_bug.cgi?id=374497 --- Comment #1 from Neviril --- Clarification/rephrasing for the expected result described above: "The assumption is that restarting Krita is needed to apply the setting and that there is no suggestion that doing so is strictly necessary to keep using the program." -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 374503] New: "Compress .kra files more" has no effect until Krita is restarted
https://bugs.kde.org/show_bug.cgi?id=374503 Bug ID: 374503 Summary: "Compress .kra files more" has no effect until Krita is restarted Product: krita Version: 3.1.1 Platform: Other OS: MS Windows Status: UNCONFIRMED Severity: minor Priority: NOR Component: general Assignee: krita-bugs-n...@kde.org Reporter: nevinevi...@yahoo.com Target Milestone: --- =Description of the bug= The option: Configure Krita > General > Miscellaneous > "Compress .kra files more" ...does not appear to have immediate effects on file size when saving an image. This seems to be the case both with the active image and with a newly opened image. Only after Krita is restarted the option appears to work as intended. In my test case I verified that after restarting the program the option was able to decrease a 796 kB .kra file into a 743 kB file. Without restarting the program the file size would not decrease upon saving (also after making sure that the image was "dirty"). =Expected Result= Either the option should work immediately or the user should be notified that Krita needs to be restarted for it to have any effect. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 374503] "Compress .kra files more" has no effect until Krita is restarted
https://bugs.kde.org/show_bug.cgi?id=374503 --- Comment #2 from Neviril --- Created attachment 103191 --> https://bugs.kde.org/attachment.cgi?id=103191&action=edit Compress option results I tried again today with a new image, saving the image as a new file every time the option was changed. I was able to reproduce the minor issue in that only after the program is restarted the option starts having an effect. Odd. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 374958] New: Problems with 16 and 32 bit float .tiff export
https://bugs.kde.org/show_bug.cgi?id=374958 Bug ID: 374958 Summary: Problems with 16 and 32 bit float .tiff export Product: krita Version: 3.1.1 Platform: Other OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: File formats Assignee: krita-bugs-n...@kde.org Reporter: nevinevi...@yahoo.com Target Milestone: --- Created attachment 103370 --> https://bugs.kde.org/attachment.cgi?id=103370&action=edit Sample image OS: Windows 10 64bit Issue: Exporting a .kra drawing to .tiff file appears to fail to produce a usable result if the color space has been set to be 16 or 32 bit float. The output file is a very faint transparent image. On the other hand, 8 or 16 bit integer image .tiff export appears to work correctly. It's worth noting that re-opening the same exported image in Krita does not seem to show any issue. The result fails with: - IrfanView 4.42 (a popular Windows image viewer) - GIMP 2.8.14 (the file will be automatically converted to 8bpc upon importing) - XnView MP 0.83 (16 bit float fails but oddly .tiff files exported in 32 bit float seem to work fine) -- You are receiving this mail because: You are watching all bug changes.
