I would like to be able to view images in Calc which are located inside cells. As simple as that. This is an actual need, I am not making this up, so don't close as "not needed" or "works for me". If you do, it'll show you don't necessarily care about what your users need and instead would like to push Calc in the direction of your own vision of what Calc should be. Currently Calc missing this functionality has me and others like me relegated to ugly hacks (see below), Google Spreadsheets, or a myriad of web-based solutions cobbled together from Wordpress or Drupal. This shouldn't be necessary for legitimate uses of a spreadsheet. This functionality can do a lot for Calc, from enabling uses of Calc that are perfectly natural for the users (and are already being done by inferior, kludgy web software), to drawing the attention of skilled minds and developers in the Machine Learning and Computer Vision communities. I will describe the functionality I'd like below, but first let's dispell the myth that this feature is not necessary in Calc. Here are reasons people have cited for not implementing this feature over the years: Q: Calc cells are for data. Images are not data. / Calc is not Writer. It does not need pretty images. A: Calc needs images. I have a spreadsheet of physical things and when I have to pick it up from storage I need to know what it looks like, because that's what I search for. I am not going to describe them like "small round object with green sides and a blue dot" just because I can't have images. Or let's say I have a list of people who are working with me, I would like to see the picture of the person so they're not just faceless numbers on a list and I can immediately associate the data to who they are. Or maybe display stock tickers on a spreadsheet of stocks. Myself, I would like to see how much items are currently being sold for on the internet, so I would make graphs of that, to see trends and buy/sell smart. Images are data. Calc is NOT a programming language. If you think "data" only means text, then you are terribly wrong. Calc is made for usage by humans, and images carry a lot of information for humans, information which can NOT be replaced by text information. Calc is for data, and calc is for humans, therefore it should display data for humans, and that means images too. Q: Calc cannot make meaningful use of image data. A: So implement features like this as well rather than go "stuff is not implemented so let's not implement stuff". Examples: search/sort by color, by EXIF data, by aspect ratio. Ability to access the bitmap from the scripting language to perform machine learning algorithms. Ability to modify bitmap data to display visualizations. For example, LO already has the ability to run JavaScript. With a place to output images we could have d3.js visualizations associated to our row or column data in a meaningful way. We could have location data displayed as an *actual map* in the cell. We could have addresses displayed beside street view photos of them to help finding them. Q: Add an image and anchor it to a cell. A: Doesn't work for me. First of all it's very fiddly. Most importantly, when you resize or sort data the images don't follow the data, since an image anchored to B3 will always be anchored to B3, even if the data moved down to B12. Second of all, I can't easily resize the image to look at it in detail. Also, the functionality often doesn't work, images get distorted, get resized improperly, or don't show up at all. When you save and re-open the document, they get shifted around and you don't know what cell they were assigned to before. Q: Use a comment. Put it in the background, and edit its formatting options. A: Doesn't work for me. Even though sorting makes images move around together with the data, it's still pretty crappy. First of all, I can't easily resize the cell to get a larger image to see it better. Second of all, the amount of manual work you have to do is huge. I need to add a comment, add some text inside it, exit the comment, right click the comment, select the background options, create a new bitmap, import it, then resize the comment, move it into the cell, and resize the cell, then move the comment into the background. When resizing the comment I need to get it just right because this ugly hack makes the image tile and I need the image once only. Additionally, since *none* of the images I have on disk will be the right size, I will have to resize the image in an external editor, and save it out. This is all terrible. ----------- What I request (functionality that HAS to be implemented for my issue to be resolved): 1. A simple way to display an image in a cell. This should be ~5 clicks max. The cell probably shouldn't hold text at the same time as an image. This is not a formatting option, this is a data option, so don't make it a formatting option. 2. The image should resize to the cell, take up the whole cell, resized with aspect ratio, touching edges from the inside. Resizing the cell should make the image larger. 2a. There should be a formatting option that says the image should touch the cell from the outside, not the inside, i.e. it is being cropped. 2b. There should be a formatting option that says the image should go into "touch from outside" mode below a certain width or height, specified in text lines. 2c. There should be a formatting option that specifies the vertical/horizontal alignment when the image is in "touch from outside" mode. top/center/bottom, left/center/right. 3. Image follows data around through sorting, copy/paste, deletions of rows above, etc. 4. A simple one-click way to display the image full-size, maybe a small magnifying glass icon that shows up if you hover the image. 5. The ability to import the image using a macro. You edit the cell and go =image("file.jpg") or =image("http://file.jpg") and the cell now displays the image. This needs to work during CSV import too. File names that appear relative are loaded from the directory the spreadsheet was saved to, or if none, current working directory. There should be an ability to load images from absolute paths. There should be an ability to load from URL. Once loaded the images are stored inside the spreadsheet file. The user needs to be made aware that loading images could compromise security, e.g. someone could write a malicious spreadsheet that loads data that should be kept secret (think passwords etc). 6. The ability to zoom the image using one click. When you hover the cell, a small, transparent, magnifying glass icon should show up and when you click it the image displays over the spreadsheet (think "lightbox") until you click on it or press escape. This is "image viewing mode". 7. When in image viewing mode, moving the cursor around with arrows changes the image. 8. Moving onto a cell without an image does not exit the mode, it just displays a blank image. 9. There should be a simple keyboard combination to enter image viewing mode, or the ability to define one globally in my installation of LibreOffice Calc. 10. There should be arrows on the image viewer clicking which will move the cursor. Arrows for up, down, left, right. A cross for exiting. 11. Images show up in printouts, in the size of the cell they are in, using the specified formatting options. What I think would be useful. It would make the functionality much more valuable: 1. New data type that defines a single color in RGB or HSL mode. Those should be two separate data types, rather than convert everything to one color space, due to numerical precision. 2. An API to read image data from macros. This should be in callback style, and the call should carry information on cell size. The callback should have access to an object or variable that persists between calls (e.g. this could carry state that is very slow to load). 3. A GUI function to sort data by color proximity to a picked color. You select this from the menu, get a HSL color picker, and once you've picked the color and pressed OK, all images get evaluated by how close their colors are. For example, for each pixel you could measure the distance from the colour picked, and all pixels get averaged. The formula for this might be e.g. 1/(# pixels)*Sum_i|H(P_i) - H(picked)|. That is the average of: for each pixel, the distance from the HSL Hue of that pixel to the Hue of the picked colour. But there might be other, better comparison modes, and this should be experimented with. A better formula might be 1/(# pixels)*Sum_i L(P_i)*|S(P_i) - S(picked)|*|H(P_i) - H(picked)|. 4. A GUI function to sort data by color. Like above, but every image gets tested against every value of "Hue" using the formula: 1/(# pixels)*Sum_i S(P_i)*L(P_i)*|H(P_i) - H(searched)|. That means, saturated colours are more important than unsaturated ones. Then for each image, the H that got the highest score gets assigned to the image, and then images get sorted by H. 5. An API and a GUI function to search by formula. For example, someone could implement a computer vision library that'll let me search for all rows containing images of paper clips. 6. An API for writing to a cell's image. This should be in callback style, and the call should carry information on cell size. The callback should have access to an object or variable that persists between calls (e.g. this could carry state that is very slow to load). 7. An API to turn a cell into "image mode" and back into "text mode". I'm not sure there should be "image mode" and "text mode" but I guess so. Maybe you'll have a better idea. This has been requested a multitude of times before, over the years, by various people, without acceptable resolution. Please, this time, implement this, rather than wave it off without empathy for the necessity this carries for other people, who have other needs than you. If you don't want to implement this, or think that it does not fit your personal vision of what Calc should be, do not close this ticket, leave it open for someone else who would like to add this functionality to Calc.
(In reply to cheater00 from comment #0) > I would like to be able to view images in Calc which are located inside > cells. As simple as that. Well, lets see. For starters this would be an Enhancement. Not a bug in any sense. Cells can in fact hold images, a simple Insert. But default is to anchor to sheet (page) --so need to change to anchor to cell for any formatting or styling of the frame holding the image. Then the image does stay with the cell with any reformatting or sort. The frame takes a table:end-cell-address (when anchored to cell), and the image is either held as binary or as a link. What is admittedly missing is any handling of a cell's (<table:table-cell>) <draw:frame> and <draw:image> content as anything more than a rendered image. What you fail to understand is that this is driven not by LibreOffice requirements, but instead by requirements in the ODF 1.2 standard as to function of an OpenDocument Spreadsheet Document the container for Calc documents we create. There are several ways the Exif and other meta details of a source image could be incorporated into cell attributes--but none are specified in ODF 1.2. There is no established <table:image> format meaning anything done for LibreOffice would not transition to other ODF processors. Even if we extend the .ODS container for our use, we'd be making an interoperability issue. Also, most of your use case is already more correctly handled in a database with SQL column to hold BLOB and meta data of images. So is this even really a legitimate core requirement? I'd have to say no.
Hi Stuart, thanks for your comment. Thank you for correcting the type to "enhancement". I disagree that an SQL database is somehow a replacement for LibreOffice. There is obviously no way to use a database the same way you would use a desktop application, a lot of features are missing, let alone ones specific to Calc. If you say "but you could build a GUI", to this I can say, why implement any features, if everything could be built in assembler? An SQL database isn't even far fetched. I see your point with regards to file formats. This does however fall under "stuff is not implemented so let's not implement stuff". If you have a prerogative to absolutely never implement features unless they are portable via ODF, then I question that prerogative and would like to challenge it with whomever is responsible for that. "Insert image" is not sufficient. I'll quote the original post below: > when you resize or sort data the images don't follow the data, since an image > anchored to B3 will always be anchored to B3, even if the data moved down to > B12. Second of all, I can't easily resize the image to look at it in detail. Or in other words this does not implement list points 2-10 from the original post. Is this a legitimate core requirement? You have not supported your argument other than say "our data format is not flexible" and "here are a few things you could try" (which don't work). I believe it remains to be shown if it's not. My argument is that it is, because I need it when I use Calc, and the same feature has been requested by a multitude of people over time. It's not even a completely new feature. It's just fixing the "insert image" feature to make it actually usable beyond what it is now (it is useless). It's there, so someone already committed to it being in Calc, what remains is for the feature to become complete.
(In reply to cheater00 from comment #2) > "Insert image" is not sufficient. I'll quote the original post below: > > when you resize or sort data the images don't follow the data, since an image > > anchored to B3 will always be anchored to B3, even if the data moved down to > > B12. Second of all, I can't easily resize the image to look at it in detail. > > Or in other words this does not implement list points 2-10 from the original > post. > Sorry, one can equally question if your proposed usage of Calc is how a spreadsheet is intended to function? All else aside, LibreOffice Calc and its spreadsheet documents are intended to be compliant with current ODF standards, in particular ODF 1.2 for Spreadsheet Documents with rich data structures and methods, including increased use of the OpenCL API, for supporting the manipulation of numerical cell content and formulas. That compliance sets our scope of function and is the only "direction" and core functionality that Calc must support--in truth the project has no need for Calc to do anything more than behave as a spreadsheet document editor and user environment. Standards allow OLE content holding other ODF to be embedded into a cell (charts, graphs, even Draw images), as well as image/graphics can be embedded/linked to a cell. But the table structure of the spreadsheet is primarily to hold textual and numerical data for manipulation based on the content of cells. All else: Cells, Rows, Columns and Pages can be formatted by style, or direct formatting, for display of text or numerical content and formula results. Add to that styling for printing and report generation rounds out the functional requirements for LibreOffice Calc. Handling of images and OLE objects is limited to the styling that can be applied to their frame container--that is the scope we are obliged to support. And that alone is the scope of development and "direction" of Calc. In other words, Calc is *not* an image/graphic display environment and will likely never be made one in the sense you propose. Not saying it could not be done, but it would be out of scope for what a Spreadsheet document is intended to be from the projects perspective. Again, IMHO believe that LibreOffice Base and the OpenDocument Database Front End Document Format (ODB), of the OASIS ODF 1.2 standard, is the only correct way of populating styled Table reports holding and manipulating images and their metadata. Manipulation of that image data does not belong in a Calc spreadsheet.
Hi Stuart, thank you for explaining the direction of the project. I don't necessarily care about manipulation of image data, just about simple display of a small image in the cell, and a larger version for inspection. As you stated yourself, the functionality to display an image inside a cell is already present. In my opinion it is somewhat broken or underfeatured, that is all. WRT displaying a larger version of the image, that would have to be implemented. I do believe I have a legitimate use case here. I understand currently you are bound by the ODF format. Who do I speak to in order to change this strategy?
(In reply to cheater00 from comment #4) > Who do I speak to in order to change this strategy? You may check this page http://www.opendocumentformat.org/. But why don't you take a look at the LibO Base solution? ODF might enhance the specs to deal with cell images but never deal with all the other requirements. Another idea is to apply not only a color to the cell background but bitmaps like for areas. Is that covered by the ODF spec, Stuart?
Heiko, From what I understood from Stuart's comments background images as style information are in the standard. There is a rather broken implementation in Calc. What is missing for my use is for the images to be resized to cell size keeping aspect ratio, and a way to quickly see a larger version. Heiko I will look if it's possible to contact anyone at the ODF org, thanks for the link. OTOH who in LibreOffice is responsible for the strategy of strictly not implementing things not in ODF? I would like to present my case as well and learn the person or people's views. I will write about Base later as right now I'm on the run. Thanks
> I do believe I have a legitimate use case here. What is your actual use case - you have written a lot but you didn't describe your use case. Anyway, I would say that an image as cell background is the requirement that most people want and not really what you describe. If not then please add links to the requests in your claim: "This has been requested a multitude of times before, over the years, by various people, without acceptable resolution." More I read what you have written more I have a feeling that you have a specific use case that is not really suited for a spreadsheet program. I mean - it sounds cool but I just don't see that we would or could implement it anytime soon. > I don't necessarily care about manipulation of image data, just about simple > display of a small image in the cell, and a larger version for inspection. Why the extremely blown-up "solution" proposal then?
(In reply to cheater00 from comment #6) > OTOH who in LibreOffice is responsible for the strategy of > strictly not implementing things not in ODF? LibO is a decentral open source project. Meaning if you find a programmer who codes your ideas and if the devs accept it your stuff gone be active. Learn more at https://www.libreoffice.org/community/get-involved/. And of course you can hire one of the big companies that provide professional support (https://www.collabora.com/, https://www.cib.de/en/home.html) or a freelancer. In respect to UX your are on the right place. The design and UX group (https://www.libreoffice.org/community/design/) has weekly meetings where proposals like yours are discussed - if the ticket is in a stage that makes it necessary. This one isn't yet, IMHO.
(In reply to Tomaz Vajngerl from comment #7) > Anyway, I would say that an image as cell background is the requirement that > most people want and not really what you describe. Would it be possible to enhance the cell background like for the area style? https://design.blog.documentfoundation.org/2015/12/22/area-fill-options-made-consistent/
There is no limitation in ODF. In ODF a table has nearly the same properties no matter whether the table is part of a text document or a spreadsheet. Only the attributes, which describe the anchor, are different. When you anchor an image to a cell, it becomes part of the cell in file format. In a spreadsheet the anchor is described by the attributes table:end-cell-address, table:end-x and table:end-y. The ODF has all what is needed to get an image into a cell and stick it to the cell. But there are problems in the current implementation, especially when the row or column is resized, or row or columns inserted, removed, hidden or sorted. You will find a lot of reports with this topic in Bugzilla. It seems, that clean-up the reports is needed. Because of the problems in the current implementation, you should discuss alternatives for the purpose of a catalog on a forum.
Hi guys, the two main uses of Calc that I have are: 1. shopping for stuff 2. keeping track of stuff Scenario 1. Here's an example from yesterday. I am looking to buy a piece of exercise equipment called a "cable cross". This means I need to go and visit all the sources I can find on the internet, find out whether the item will fit purpose, find out the price, shipping cost, etc, convert that to my currency, and sort based on that. I need the following columns: - source (business I would buy it from) - name and type - price (in source currency) - shipping & handling cost - availability - lead time - shipping time - multiple columns describing the availability of features (not all cable crossovers are the same) - included extra equipment (say, grips or a bench) - the value of the extra equipment - total cost minus added value in my currency each item I find will have multiple sources. I will go through maybe 40 sources, each of which will have maybe 5-10 possible items in various configurations. Often they will sell the same item at a different cost. Quite often those items will be the same but rebranded, with a different model number. Textual representation (make + model number) will not reveal this when reviewing the data; only visual comparison will. This can save a lot of money when shopping. An image can also tell me which of the various sub-options I am looking at; say you have multiple rows for what is actually the same item but with various accessories thrown in. When shopping and making comparisons of physical items it is important to be able to immediately see what you are working with because you can remember what it is you're working with much quicker when you see an image, than when you see gibberish model numbers like WX-STA-12-0. One look at an image tells you what you would otherwise only find out if you scanned the whole row because that's how human memory works. Seeing things steamlines work. Hence my comment that spreadsheets are for humans and are more than just a programming language. Now let's say I'm shopping for those items and during the time I'm creating the spreadsheet for comparison I find out that there's a feature that makes a lot of difference in value. For example if you google for "cable cross" you will see that they have those two wheels on the side, and some of them can be moved up and down, whereas others are fixed. This adds a lot of value. Without images, I'll have to google each item separately, and look at the image, and then enter into a column whether the feature is available. If I see images vice versa the data I'm inputting, this becomes a blast. If I don't, this obviously becomes arduous. It is my experience when shopping for more expensive items I have to do this several times with all items. Scenario 2. Keep track of things I have. Here's a very simple example. Take a look at this, it's a box of guitar picks. http://i.imgur.com/HKxXNKk.jpg Tell me how to keep track of them without photos. In such a way that I can easily find them in a box full of them. Do I put a barcode on each? Do I write descriptions like "small black rounded pick"? That's never going to be meaningful. There's going to be a dozen different small black rounded picks. Coming up with visual descriptions is a fool's errand. I would like to keep track of prices over time and when I need to buy more I would also like to keep track of where I bought them in the first place. ---------------------------------------- Regarding Base. It does hold image data. However it does not display it in the spreadsheet view. It just says "<OBJECT>". That would need to be improved upon and images displayed. Then there's a lot of flexibility missing. If I come up with a new way to evaluate the efficacy of a certain purchase, that's a formula based on other data. In Calc I just enter the formula in a cell and drag down. In Base, I would have to: 1. possibly extend an existing table 2. create a new view 3. create a new form. And then it turns out that for some of the rows, the formula doesn't work, and you have to input a number by hand. At which point you've hit the ceiling. Or let's say you want to pick out some things and mark them bold or give them a yellow background. You can't in base. There's no window freezing, so very large spreadsheets can't really be worked on. An example I work on often has 36 rows and goes up to column BF. -------------- Accessibility is another reason. All in all I would say images carry a lot of data for humans. Myself, I am the kind of person that goes to great lengths to associate images of people with their names in the phone contact book. If I see a list of bare numbers or even names in my call log I get lost, with images it works well. So I guess that means I've got some sort of "dys" that makes me work better with images than text. I imagine a lot of other people are the same.
Here's a list of posts by people who would like to have images in cells in a spreadsheet, or already work with the broken feature available now, first for LibreOffice, then for OpenOffice, then for various other products. I stopped after the 10th page of Google results. I assume every time people want to insert an image into a spreadsheet it's because they want to see something that's in the image. Surely there are some weird people who just want images for styling, but that's their problem. There's no other legitimate reason to display images in cells or let alone comments to cells. Either way there's enough talk about having images in spreadsheets to show that I'm not alone in my wish for this feature. I haven't been able to find similar requests that were open on the Libre Office bug tracker that's why I submitted this feature request in the first place. It was not perfectly correct of me to say "this has been requested many times" but I do remember seeing things like that in the bug tracker several months ago and a couple years ago when I looked into this issue periodically. However, I cannot find any right now. https://ask.libreoffice.org/en/question/27904/feature-request-insert-images-into-calc-cells/ http://en.libreofficeforum.org/node/6974 http://en.libreofficeforum.org/node/9068 http://en.libreofficeforum.org/node/4200 http://en.libreofficeforum.org/node/12705 http://en.libreofficeforum.org/node/5033 http://en.libreofficeforum.org/node/5298 http://en.libreofficeforum.org/node/7812 http://en.libreofficeforum.org/node/12729 http://en.libreofficeforum.org/node/11084 https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=34544 https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=62586 https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=64941 https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=67552 https://forum.openoffice.org/en/forum/viewtopic.php?f=44&t=64249 https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=29097&start=0 https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=9341 https://forum.openoffice.org/en/forum/viewtopic.php?f=7&t=16773 https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=34187 https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=18098 https://forum.openoffice.org/en/forum/viewtopic.php?f=20&t=67822 https://forum.openoffice.org/en/forum/viewtopic.php?f=5&t=37144&start=0 https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=36641 https://forum.openoffice.org/en/forum/viewtopic.php?f=25&t=63865 https://forum.openoffice.org/en/forum/viewtopic.php?f=7&t=42794 https://forum.openoffice.org/en/forum/viewtopic.php?f=5&t=31394&start=0 https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=81910 https://forum.openoffice.org/en/forum/viewtopic.php?f=20&t=69019 https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=82432 https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=19984&start=0 https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=70489 https://forum.openoffice.org/en/forum/viewtopic.php?f=7&t=24677 https://forum.openoffice.org/en/forum/viewtopic.php?f=20&t=56904 https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=16282 https://forum.openoffice.org/en/forum/viewtopic.php?f=49&t=77106 http://superuser.com/questions/131467/inserting-an-image-into-a-openoffice-org-calc-cell http://www.linuxtopia.org/online_books/office_guides/openoffice_3_calc_user_guide/openoffice_calc_Adding_graphics_Inserting_an_image_from_a_file.html https://www.shorttutorials.com/openoffice-spreadsheet/insert-image.html http://openoffice.2283327.n4.nabble.com/OpenOffice-3-2-Calc-adding-bitmap-image-to-a-cell-td2780730.html http://ccm.net/faq/41723-openoffice-how-to-insert-images-in-comments http://www.softwaretalk.info/inserting-an-image-into-a-openofficeorg-calc-cell.htm https://www.youtube.com/watch?v=bCNfRC3-K-E https://productforums.google.com/forum/#!category-topic/docs/how-do-i/ON8hZBsfcL0 https://productforums.google.com/forum/#!topic/docs/53pHveeJ3Zs https://www.lynda.com/Sheets-tutorials/Inserting-images-spreadsheets/163414/187766-4.html https://neowiki.neooffice.org/index.php/Inserting_an_Image_Behind_Text http://www.ozgrid.com/forum/showthread.php?t=135800
Heiko, Tomaz, and Regina, have you got any other questions? Is there anything that I could clarify? Thanks
(In reply to cheater00 from comment #13) > Heiko, Tomaz, and Regina, have you got any other questions? Is there > anything that I could clarify? Thanks Lengthy posting, didn't read every argument ;-) In Draw/Impress and maybe as well Writer you can add a table that has all flavors of area fill including bitmaps. Obviously users expect that Calc has the same options, there was the same request on G+ today.
Going ahead and setting this to NEW. If anybody disagrees, that this is a valid enhancement request, feel free to set this to invalid / wontfix.
I will work on this. The first thing is to make images move with the cell when the cell moves (e.g. when sorting). As I understand this is the most annoying thing. We can then think if we anchor images to cells by default. Currently they are anchored to the page by default. Also an option for the image to automatically resize with the cell surely would be nice.
Very very happy this is happening. Thanks you for picking it up. Please let me know if you need any feedback. When inserting and scaling images please make sure they use cubic interpolation and get scaled proportionally. Please make sure this works well with a spreadsheet that has > 300 1080p images in a system with 4 gb of ram (i guess that means unloading ones that are not visible). Being able to click to see a full size image would be great. Or hover. Or both. This could be a formatting option.
(In reply to Samuel Mehrbrodt (CIB) from comment #16) > I will work on this. Please consider using the cell fill style > bitmap property (comment 5). In particular to replace 'Format Cells > Background' by the new all-in-one area fill frame including gradient, hatching etc. but primarily because access to bitmap alignment could be made consistent.
I'd like to note that if this requires tok much clicking to add a single image it will be impractical. Best case scenario: being able to do eg =IMAGE("url-here").
(In reply to cheater00 from comment #17) > When inserting and scaling images please make sure they use cubic interpolation and get scaled proportionally. Scaling interpolation algorithm is out of scope of this bug. Anyway, bi-linear (upscale) / averaging (downscale) makes more sense for speed and lanczos for quality (but with an insane performance hit). Anyway the scaling interpolation algorithm used will need to be the same as everywhere else in LO. > Please make sure this works well with a spreadsheet that has > 300 1080p images > in a system with 4 gb of ram (i guess that means unloading ones that are not > visible). Out of scope of this bug as it will use the bitmap functionality that is already present in LO. > Being able to click to see a full size image would be great. Or hover. Or both. > This could be a formatting option. Also out of scope but sounds like a good idea. I haven't seen it before. You might file a separate bug for this once this bug is implemented.
Tomaz re the interpolation: all it needs to do is look good. So the exact algorithm doesn't matter, you are right. Regarding other points: you seem to want something than the original bug reporter (me btw). Why not open your own bug? In the end Samuel will decide what he wants to work on, and that's what really defines the scope. I can only provide context that explains what would be useful to me to at least partly enable the scenario for which i reported the bug in the first place.
(In reply to cheater00 from comment #21) > Regarding other points: you seem to want something than the original bug > reporter (me btw). Why not open your own bug? Huh? Please check that attitude--there is no ownership of an issue. If Tomaž actually needed to implement this he would. But since the use case remains rather weak, hes made valid observations on any likely implementation. > > In the end Samuel will decide what he wants to work on, and that's what > really defines the scope. I can only provide context that explains what > would be useful to me to at least partly enable the scenario for which i > reported the bug in the first place. No, Tomaž and Samuel will likely work on this together... in the end the result will be what is in scope for current table/spreadsheet cell object framework and graphics handling within that context.
You're right - it wasn't clear to me who would be working on it - sorry
Created attachment 139094 [details] Example spreadsheet with images to be sorted
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3a2a430ae8e2c1647c18d8904477949f6e2e7941 tdf#98931 Consider cell-anchored images when sorting It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #25) > Samuel Mehrbrodt committed a patch related to this issue. With this commit, sorting images anchored to cells works. Further improvements should go in separate bugs. Examples: * Improve resizing behavior (bug 114552) * Add option on insert image dialog to set image's anchor type (bug 86739) Feel free to also create one with the "show large image on click" feature request. That's an unrelated feature request, but maybe useful for some. Also please test and let me know of any issues you encounter.
*** Bug 100987 has been marked as a duplicate of this bug. ***
*** Bug 104901 has been marked as a duplicate of this bug. ***
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b5f8b046008a27f1da58b934dbe61c0decf36612 tdf#98931 Add option to sort boundary image-only columns It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9f329c08e6b7e87879545c1bd78a4d3435fc44e4 tdf#98931 Test for sorting images It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 140692 [details] Simple teaching example (from the web) that needs images in cells
(In reply to Christopher R Lee from comment #31) > Created attachment 140692 [details] > Simple teaching example (from the web) that needs images in cells What does this mean? How is that related to this bug?
(In reply to Samuel Mehrbrodt (CIB) from comment #32) > (In reply to Christopher R Lee from comment #31) > > Created attachment 140692 [details] > > Simple teaching example (from the web) that needs images in cells > > What does this mean? How is that related to this bug? Sorry, the associated comment somehow disappeared. It was basically to say thank you for implementing the proposal. I thought it worth adding to the record, for the benefit of other teachers searching for solutions, that this will be great for foreign language teaching. We like to print or display sequences of words and phrases, with or without associated images. The attachment is an illustrative text-only example made from the Calc extension BingoCards-3.1.3. With 6.1.0 we will be able to include images.
(In reply to Christopher R Lee from comment #33) > We like to print or display sequences of words and phrases, with or without > associated images. The attachment is an illustrative text-only example made > from the Calc extension BingoCards-3.1.3. With 6.1.0 we will be able to > include images. Good to hear it works for you :)
In the original description of the feature request > 3. Image follows data around through sorting, copy/paste, deletions of rows above, etc. Copy/paste are not working. Excel supports the functionality. I filed a new bug report Bug 116510
(In reply to Luke from comment #35) > In the original description of the feature request > > > 3. Image follows data around through sorting, copy/paste, deletions of rows above, etc. > > Copy/paste are not working. Excel supports the functionality. I filed a new > bug report Bug 116510 I think I'll wait for 6.1.0 before doing anything; software does take time to develop and debug. However, at the risk of going OT, I do agree with the sense if not the tone of this discussion, which concerns a tendency of LO and ODF developers to decide for themselves what users should be wanting. Inescapably, user requirements are conditioned by the M$ offerings, which are likely to stagnate for want of effective and popular competition. Defining user requirements is a very old subject which predates the open source movement. In the present case, the widespread preference among users who don't know much IT is to do everything with the wordprocessor, spreadsheet and drawing modules. Spreadsheets do lists of items very well, and database software is much too hard to learn for occasional use. The remaining show-stopper with Calc is (as stated in the LO documentation!) the continuing absence of an easy learning curve for macro programming in the preferred Python environment. I had the misfortune to make extensive use of VBA before retiring, and my present requirements are really very simple and not mission-critical - just providing controls to move around a sheet and copy/paste items. As I said elsewhere, I help out several local voluntary organisations, where many colleagues do some office computing at work. Not one of the people I have met uses LO, and few know of its existence. Incidentally, the same applies to Linux despite the fact that some of the people we try to help can't afford a computer.
*** Bug 42705 has been marked as a duplicate of this bug. ***
I found a bug with shrinking cells that are set to resize. Filed as Bug 116836
I found a bug with rotated objects anchored to cells, move when saved. Filed as Bug 116892
I found a bug with rotated objects anchored to cells w/ resize, incorrectly move when their parent cell is moved. Filed as Bug 116931
Verified Fixed on Versió: 6.1.0.0.alpha1 (x64) ID de la construcció: cb47f0d320994e001bc38dc2ee9b7d957b15e6ab Fils de CPU: 4; SO: Windows 10.0; Renderitzador de la IU: GL; Configuració local: ca-ES-valencia (ca_ES); Calc: group
https://digitaleguide.com/how-to-block-airtel-sim-online
(In reply to Xisco Faulí from comment #40) > *** Bug 42705 has been marked as a duplicate of this bug. *** Um, Bug 42705 was submitted ~5 years before this one. How is it possible that it can be a duplicate of this report? Isn't there a protocol to all of this? Shouldn't the later report of the same bug ALWAYS be the duplicate? Otherwise it can all become a tangled mess.
How To Find Your Reliance Jio SIM Number By Running https://allussdcodes.com/jio-mobile-number-check/Jio Mobile Number Check USSD Codes, Check Own Jio Number
How To Know My Jio Mobile Number, Jio Mobile Number Check Code https://allussdcodes.com/jio-mobile-number-check/
How To Check Aadhar Card Mobile Number Online Via UIDAI Site, Aadhar card me Mobile Number Kaise Check Kare https://aadhaarsewa.in/check-adhaar-card-linked-mobile-number/
How To Remove Aadhar Card PDF password Online https://english.aadhaarsewa.in/remove-aadhar-card-password/