[GitHub] [openoffice] cbmarcum commented on pull request #164: Update EditEngine code to use 32 bit paragraph storage
cbmarcum commented on PR #164: URL: https://github.com/apache/openoffice/pull/164#issuecomment-1374548388 > > Copy/Paste from Firefox to Calc trunk and this PR all 2 rows for both > > There is no way all 2 pasted successfully over HTML on trunk. Either the transfer format wasn't HTML, or you tested something other than trunk. Hi Damjan, You are correct. I found out what was wrong with my test. I had copied from a Firefox outside of the VM and pasted to AOO inside the VM. This opened a Text Import dialog and did import all 2 rows in both trunk and the PR. I can confirm that copying from Firefox and pasting into AOO within the same VM results in: trunk getting to row 13106 and inserting a lot (or all) of the rest into column D of the next row. The PR build takes all 2 rows. Both without using the Text import dialog. Sorry for the confusion. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Marketing Mailing List
The marketing mailing list has a deteriorating level of usefulness. Since 2014 there have been 330 posts, the majority of which had very little to do with the "marketing" the software or promotion of the project: Year Posts 2014 211 2015 40 2016 43 2017 21 20184 20192 20203 20213 20223 Total 330 Apart from the small flurry of activity in 2014 just before Rob Weir retired from the project. the mailing list has served almost no useful purpose, other than to attract a steady 24/7 stream of spam posts. Since the project doesn't engage in any marketing activity and those few events at which we attend are normally discussed on the dev list, I propose that, unless any member of the project can offer any clear and fully justifiable reason for doing otherwise, we shut down the "spam bait" marketing list. Dave - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[GitHub] [openoffice] DamjanJovanovic commented on pull request #164: Update EditEngine code to use 32 bit paragraph storage
DamjanJovanovic commented on PR #164: URL: https://github.com/apache/openoffice/pull/164#issuecomment-137456 > Copy/Paste from Firefox to Calc trunk and this PR all 2 rows for both There is no way all 2 pasted successfully over HTML on trunk. Either the transfer format wasn't HTML, or you tested something other than trunk. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[GitHub] [openoffice] cbmarcum commented on pull request #164: Update EditEngine code to use 32 bit paragraph storage
cbmarcum commented on PR #164: URL: https://github.com/apache/openoffice/pull/164#issuecomment-1374528032 My latest testing: File > Open set file type filter to HTML Document (OpenOffice Calc) (*.html;*.htm) trunk got to row 13106 with PR 164 got all 2 rows --- Copy/Paste from Firefox to Calc trunk and this PR all 2 rows for both --- Copy/Paste from Firefox to Writer trunk and this PR all 2 rows as tab separated values per row. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Noch ein Termin - T-DOSE 2023
Moin, Ich hatte ja aus gegebenem Anlass das eine AOO-Poster aktualisiert und drucken lassen: https://www.dropbox.com/s/498cohi0fiv7dik/AOO_poster_de_color_240822.pdf?dl=0 Die Druckqualität gefällt mir, soll ich noch ein paar nachordern und zu euch liefern lassen? Der Stand-PC (bzw. die Windows-VM) müsste ja auch mal wieder aktualisiert werden... Gruß, Matthias Am 07.01.23 um 15:10 schrieb Dr. Michael Stehmann: > Hallo, > > die T-DOSE ist eine freie, jährliche Veranstaltung in den > Niederlanden, um die Nutzung und Entwicklung Freier Software zu promoten. > > Im Jahr 2023 kehrt sie auf die Agenda zurück. > > Sie findet am 22. und 23. April 2023 in Geldrop bei Eindhoven > > https://t-dose.org/ > > Auch wir haben dort (wieder) einen Stand. > > https://t-dose.org/2023/projects/ > > Die T-DOSE ist eine sehr übersichtliche Veranstaltung mit > hochklassigen Vorträge und einer geradezu familiären Atmosphäre. Und > Eindhoven ist fast nicht weiter weg als St. Augustin. > > Da Mechtilde und ich werden wieder den Stand betreuen, aber Helfer > sind willkommen. > > Mit freundlichem Gruß > Michael smime.p7s Description: S/MIME Cryptographic Signature
T-DOSE 2023
Hello, T-DOSE 2023 will be held on the 22nd and 23rd of April 2023, at a new location the Weeffabriek in Geldrop (near Eindhoven). T-DOSE is a free and yearly event held in The Netherlands to promote use and development of Free Software. During this event, Free Software projects, developers and visitors can exchange ideas and knowledge. https://t-dose.org/ Apache OpenOffice will have a booth at T-DOSE again. https://t-dose.org/2023/projects/ Mechtilde and I will maintain this booth, but helpers are cordially welcome. Kind regards Michael OpenPGP_signature Description: OpenPGP digital signature
Noch ein Termin - T-DOSE 2023
Hallo, die T-DOSE ist eine freie, jährliche Veranstaltung in den Niederlanden, um die Nutzung und Entwicklung Freier Software zu promoten. Im Jahr 2023 kehrt sie auf die Agenda zurück. Sie findet am 22. und 23. April 2023 in Geldrop bei Eindhoven https://t-dose.org/ Auch wir haben dort (wieder) einen Stand. https://t-dose.org/2023/projects/ Die T-DOSE ist eine sehr übersichtliche Veranstaltung mit hochklassigen Vorträge und einer geradezu familiären Atmosphäre. Und Eindhoven ist fast nicht weiter weg als St. Augustin. Da Mechtilde und ich werden wieder den Stand betreuen, aber Helfer sind willkommen. Mit freundlichem Gruß Michael OpenPGP_signature Description: OpenPGP digital signature
Re: ByteString vs Strbuf vs OString
On Sat, Jan 7, 2023 at 9:51 AM Peter Kovacs wrote: > Hi all, > > > I have an emotional issue and I need some help. > > I think the classes mentioned in subject are all crap. They are all ugly > and I do not want to use any of them. > > I would like to remove them. And replace them with > > > std::basic_stringstream > > > std::string > > > But this is a huge and fundamental change. What I would like to do is to > hollow out the classes we use, one by one, until everything is using std > classes or can cast to. Then remove the now obsolete classes within the > code. > > any objections? > > Hi Please leave them alone. They all have their purpose, and they work in very specific ways to accomplish their tasks. The main/tools String with its 16 bit length, saves space for the large number of strings in Calc cells. The main/sal OString and OUString are 32 bit and copy-on-write, like Java's java.lang.String. Also UNO serializes to and from OUString for C++. I do agree that string type changes will be necessary in some cases. For example if we want to increase our 16 bit limit on maximum paragraph size to 32 bits, we will probably have to change the tools String to a longer string type. The real crap classes that should be replaced ASAP are the 16 bit main/svl PTRARR, which I replaced in 2 places in https://github.com/apache/openoffice/pull/164, but which is used in another 53 places ( http://opengrok.openoffice.org/search?project=trunk=SV_DECL_PTRARR==full). Many 16 bit limits come from that class. And I now discovered another 22 usages of SV_DECL_PTRARR_SORT. The problem is, that has many knock-on effects, as is clear from the size of my PR. We also have a bunch of primitive pre-STL main/tools classes like Container and List, written around 1994 and generally not very good at anything, including performance. Yes, the way C++ is used in OpenOffice is unusual and foreign to everyone. But eventually it makes sense. Start with one of the more recently developed modules, like the OOXML filter in main/oox, or the Base application in main/dbaccess, which were written closer to 2010 and are much cleaner, easier to read and understand, use STL containers, etc. I've been improving that OOXML filter lately and could help you get started. Regards Damjan
Re: Open letter to @Dave Fisher and @Pescetti.
Maybe my English has let me down, I didn't mean you didn't do anything, but there are no results yet. I know that we are all volunteers, including me. Regards. charlie - Messaggio originale - Da: "Andrea Pescetti" A: "dev" Inviato: Sabato, 7 gennaio 2023 7:26:56 Oggetto: Re: Open letter to @Dave Fisher and @Pescetti. casa...@email.it wrote: > For months I have been asking for help to fix a registration problem on the > Italian AOO forum. You both promised me you'd step in, but so far you haven't. We are all volunteers and we do what we can. The fact that you didn't see anything doesn't mean that we did nothing. I will give updates in the appropriate threads (not this one) within a few days. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
