Re: Proof of concept patch for bug 4812.
Bo Peng wrote:
Dear all,
3. Use this expandable unknown layout for a document without valid layout.
} else {
// a warning will be given for unknown class
- setBaseClass(defaultBaseclass());
+ setBaseClass(unknownBaseclass());
Independently of the local layout problematic I think this last change
goes in the right direction; I never liked LyX to switch automatically
to whatever default layout, resulting in dataloss when the default
layout is article and the document has level one sections for example.
return classname;
}
The result:
1. A document without valid layout will be opened with a warning. (The same)
2. All layouts are usable, although they all look like standard (changed)
3. Save such a document will not lose data. The original layout name
will be used. (improved)
4. Another layout can be chosen from Document - settings, if a
correct textclass is selected, all layouts will work fine. (improved,
because the current approach will change some unknown layouts to
standard.)
I think this is not enough. If the local layout is to be supported,
there should be a way to select this option in the document settings. If
you select this option, LyX should be able to reformat the document
dynamically if a proper local layout is found, or switch to the unknown
layout if not found.
The biggest problem with this patch is that because layout pointers
are used directly, LayoutList, which is std:;vectorLayout can not be
expanded dynamically. I change it to std::listLayout to allow
dynamic growth of the unknown textclass but this may lead to
performance problems.
This is wrong IMHO, the vector should stay and you should just construct
this unknown layout together with all the others.
Any opinion is welcome.
You have mine. I guess this patch will bring back the debate around the
usefulness of the local layout stuff, I am no expert on this stuff so I
won't comment any further. But please no heated debate; as the 1.6
maintainer, the last decision is on Jûrgen's shoulder and, if he makes
one, it should be respected without any further discussion.
Abdel.
Why do we need ImageMagick at all?
Hi, Question to image conversion experts: While I agree that ImageMagick is required for more specialized formats(*), we support already most common raster image formats thanks to Qt, without the need for ImageMagick; for ps/pdf/eps conversion to png, we should just use ghostscript directly. Why you might ask? Because we will remove one hard-dependency (at least for Mac and Windows) and we would also be free of ImageMagick bugs. There's probably some use cases that I miss so that's why I thought I could ask... Abdel. * Even for those, using the original program is often (if not always) a better choice than using ImageMagick.
Re: Proof of concept patch for bug 4812.
Bo Peng wrote: 1. A document without valid layout will be opened with a warning. (The same) 2. All layouts are usable, although they all look like standard (changed) 3. Save such a document will not lose data. The original layout name will be used. (improved) 4. Another layout can be chosen from Document - settings, if a correct textclass is selected, all layouts will work fine. (improved, because the current approach will change some unknown layouts to standard.) This looks like a sensible approach in general. Is the document class then not reset? So if I have ClassX, and this is not found, will LyX keep this ClassX unless I manually switch to another class? (This is the way it should be IMHO). Generally speaking, I'm glad to see that the hiding of the browse button finally triggered some action. Actually, this is what I intended with this rather rude step ;-) Jürgen
Re: Proof of concept patch for bug 4812.
4. Another layout can be chosen from Document - settings, if a correct textclass is selected, all layouts will work fine. (improved, because the current approach will change some unknown layouts to standard.) I think this is not enough. If the local layout is to be supported, there should be a way to select this option in the document settings. If you select this option, LyX should be able to reformat the document dynamically if a proper local layout is found, or switch to the unknown layout if not found. This is already the case. If we restore the browse button, users can browse a local layout and apply it. The biggest improvement is that, before this patch, layouts that are unknown to article.layout will be changed to standard, and will NOT be restored when a correct layout is selected. With this patch, the unknown layouts are kept although they look like standard. The biggest problem with this patch is that because layout pointers are used directly, LayoutList, which is std:;vectorLayout can not be expanded dynamically. I change it to std::listLayout to allow dynamic growth of the unknown textclass but this may lead to performance problems. This is wrong IMHO, the vector should stay and you should just construct this unknown layout together with all the others. I do not know how to do this. Layouts of other textclasses are loaded before layout pointers are assigned to paragraphs. This unknown textclass will grow when an unknown layout is encountered, which invalidates pointers of previously identified layouts if vectorLayout is used. You have mine. I guess this patch will bring back the debate around the usefulness of the local layout stuff, I am no expert on this stuff so I won't comment any further. But please no heated debate; as the 1.6 maintainer, the last decision is on Jûrgen's shoulder and, if he makes one, it should be respected without any further discussion. As far as I am concerned, this bug has little, if any, to do with local layouts, and removing the local layout feature does not fix this problem at all. Bo
Re: Proof of concept patch for bug 4812.
This looks like a sensible approach in general. Is the document class then not reset? So if I have ClassX, and this is not found, will LyX keep this ClassX unless I manually switch to another class? (This is the way it should be IMHO). Yes. All layouts are kept, although the textclass is named Unknown text class (unavailable) in Document - Settings. Users can edit and save this document as usual even if no valid layout is selected, although the document may not be compilable. The 'layout conversion' process only happens when another layout is selected from the textclass list, or from disk as a local layout. Generally speaking, I'm glad to see that the hiding of the browse button finally triggered some action. Actually, this is what I intended with this rather rude step ;-) It worked. :-) Bo
Re: Why do we need ImageMagick at all?
Abdelrazak Younes wrote: While I agree that ImageMagick is required for more specialized formats(*), we support already most common raster image formats thanks to Qt, without the need for ImageMagick; for ps/pdf/eps conversion to png, we should just use ghostscript directly. Why you might ask? Because we will remove one hard-dependency (at least for Mac and Windows) and we would also be free of ImageMagick bugs. There's probably some use cases that I miss so that's why I thought I could ask... i would ask whether we easily get some features like antialiasing. i guess we also use imagemagick for preparing pictures for latex generation, so it would lead to schizophrenic state that some pictures are converted via qt others via imagemagick, which is not good concept i think. but i dont know this part of code well. pavel
Re: Proof of concept patch for bug 4812.
Bo Peng wrote: The biggest problem with this patch is that because layout pointers are used directly, LayoutList, which is std:;vectorLayout can not be expanded dynamically. I change it to std::listLayout to allow dynamic growth of the unknown textclass but this may lead to performance problems. This is wrong IMHO, the vector should stay and you should just construct this unknown layout together with all the others. I do not know how to do this. Layouts of other textclasses are loaded before layout pointers are assigned to paragraphs. This unknown textclass will grow when an unknown layout is encountered, which invalidates pointers of previously identified layouts if vectorLayout is used. This makes the use of layout pointers seem kind of fragile. Maybe we should just store the name of the layout instead, and then use TextClass::operator[] to find the layout when we need it. There may be other benefits to doing it that way, too. Another option: Does the unknown TextClass really have to have umpteen copies of the same thing? Can't it just pretend that it does? Lookup is via operator[]---and it could be tuned always to return the same thing, if we're dealing with the unknown TextClass. Richard
Re: Proof of concept patch for bug 4812.
rgheck wrote: Bo Peng wrote: The biggest problem with this patch is that because layout pointers are used directly, LayoutList, which is std:;vectorLayout can not be expanded dynamically. I change it to std::listLayout to allow dynamic growth of the unknown textclass but this may lead to performance problems. This is wrong IMHO, the vector should stay and you should just construct this unknown layout together with all the others. I do not know how to do this. Layouts of other textclasses are loaded before layout pointers are assigned to paragraphs. This unknown textclass will grow when an unknown layout is encountered, which invalidates pointers of previously identified layouts if vectorLayout is used. This makes the use of layout pointers seem kind of fragile. Maybe we should just store the name of the layout instead, and then use TextClass::operator[] to find the layout when we need it. There may be other benefits to doing it that way, too. If there's no performance problem, that sounds good. But only if the changes are safe and not too intrusive. Abdel.
Re: Why do we need ImageMagick at all?
Abdelrazak Younes [EMAIL PROTECTED] writes: Hi, Question to image conversion experts: While I agree that ImageMagick is required for more specialized formats(*), we support already most common raster image formats thanks to Qt, without the need for ImageMagick; for ps/pdf/eps conversion to png, we should just use ghostscript directly. Well, you should make a list of all formats and see what conversions are or are not handled. AFAIK, imagemagick is used as backup solution in many cases. And there is nothing that really forces us to install or not IM. It is just a converter among others (or it should). JMarc
Re: Proof of concept patch for bug 4812.
Bo Peng [EMAIL PROTECTED] writes: 1. A document without valid layout will be opened with a warning. (The same) 2. All layouts are usable, although they all look like standard (changed) 3. Save such a document will not lose data. The original layout name will be used. (improved) 4. Another layout can be chosen from Document - settings, if a correct textclass is selected, all layouts will work fine. (improved, because the current approach will change some unknown layouts to standard.) Although I did not check the details, this is something I have been wanting to do for a long time. JMarc
Re: Proof of concept patch for bug 4812.
This makes the use of layout pointers seem kind of fragile. Maybe we should just store the name of the layout instead, and then use TextClass::operator[] to find the layout when we need it. There may be other benefits to doing it that way, too. If there's no performance problem, that sounds good. But only if the changes are safe and not too intrusive. The performance impact will be big because this layout pointer is used everywhere. Even storing layout index is better than storing their names. Anyway, my guess is that if layout pointers are used directly, using listLayout or dequeLayout should not cause significant performance problem. JMarc may know more about this LayoutList stuff. Bo
Re: Proof of concept patch for bug 4812.
Bo Peng wrote: This makes the use of layout pointers seem kind of fragile. Maybe we should just store the name of the layout instead, and then use TextClass::operator[] to find the layout when we need it. There may be other benefits to doing it that way, too. If there's no performance problem, that sounds good. But only if the changes are safe and not too intrusive. The performance impact will be big because this layout pointer is used everywhere. Even storing layout index is better than storing their names. Using names would mean a map or a hash table (better) instead of a vector (which could lead to index based access). Maybe the perfomance impact would not be that big... one has to try. Anyway, my guess is that if layout pointers are used directly, using listLayout or dequeLayout should not cause significant performance problem. JMarc may know more about this LayoutList stuff. The expert nowadays is Richard ;-) Abdel.
Re: Proof of concept patch for bug 4812.
The performance impact will be big because this layout pointer is used everywhere. Even storing layout index is better than storing their names. Using names would mean a map or a hash table (better) instead of a vector (which could lead to index based access). Maybe the perfomance impact would not be that big... one has to try. Actually, I was wondering why we need to define operator[name] instead of using std::map directly. Because insertion will not invalidate any pointer in a map, a map will work fine with the proposed patch. Whether or not replace Layout* with a name can be discussed later. Bo
Re: Proof of concept patch for bug 4812.
Abdelrazak Younes wrote: Bo Peng wrote: This makes the use of layout pointers seem kind of fragile. Maybe we should just store the name of the layout instead, and then use TextClass::operator[] to find the layout when we need it. There may be other benefits to doing it that way, too. If there's no performance problem, that sounds good. But only if the changes are safe and not too intrusive. The performance impact will be big because this layout pointer is used everywhere. Even storing layout index is better than storing their names. Using names would mean a map or a hash table (better) instead of a vector (which could lead to index based access). Maybe the perfomance impact would not be that big... one has to try. Yes, I'm not at all sure how often we actually need to access a paragraph's layout. And I thought about converting LayoutList to a mapstring a while ago, but didn't do it. And index-based access is also worth a thought, too. That would be OK, as long as we only ever expanded the list of layouts at the end. But this would not be unintrusive now, I don't think. Anyway, my guess is that if layout pointers are used directly, using listLayout or dequeLayout should not cause significant performance problem. JMarc may know more about this LayoutList stuff. The expert nowadays is Richard ;-) I don't have any problem with the list idea. As I said, the worry was just that pointers are starting to seem fragile. We've always used pointers, or something of the sort, I think, but maybe there is a better way. But certainly the (mislabeled) LayoutList (which has also been around forever, in one form or another) was never intended to be dynamic, and that's the root of the problem. rh
Re: [Cvslog] r25373 - in /lyx-devel/trunk/src: Paragraph.cpp Paragraph...
On Tue, Jun 24, 2008 at 9:25 AM, Bennett Helm [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2008 at 8:52 AM, Jean-Marc Lasgouttes [EMAIL PROTECTED] wrote: This is candidate for branch too. More problems remain in work skipping, but eating insets was the worst. With this additional patch, word movement should be closer to what the mac does. It works through a lyxrc setting word_forward_goes_to_end (!) that is not associated to a UI element but can be set in lyxrc.dist. I'm not sure what the status of this is now, but having just updating 1.6svn after a week of being away, I notice that moving by word stops at *both* word beginnings and word endings, whether moving forwards or backwards. Am I missing something? Bennett
Re: python help needed
Jürgen Spitzmüller wrote: In order to fully fix bug 4927, we need to do some LaTeX-LyX conversion, because subfigure captions can contain LaTeX constructs such as \label. Currently, subcaptions with such constructs are simply eaten (i.e., dataloss). I think we should factor out the routines of convert_latexcommand_index to a helper function which is used by convert_latexcommand_index, convert_subfig and maybe others. I failed at doing this due to limited python knowledge. I'd appreciate if someone could jump in (and maybe also clean up my really ugly convert_subfig routine). I finally got around to doing this. I've also re-written the latex2lyx conversion routine so that it uses the unicodesymbols file. I'm not sure exactly what you had in mind for convert_subfig, as I don't know anything about figures, but perhaps this will let you do it now? rh
Re: Proof of concept patch for bug 4812.
rgheck [EMAIL PROTECTED] writes: Yes, I'm not at all sure how often we actually need to access a paragraph's layout. And I thought about converting LayoutList to a mapstring a while ago, but didn't do it. And index-based access is also worth a thought, too. That would be OK, as long as we only ever expanded the list of layouts at the end. AFAIR, we used to use layout names, but this was changed to using pointers after a profiling session from Lars. JMarc
Re: [Cvslog] r25373 - in /lyx-devel/trunk/src: Paragraph.cpp Paragraph...
Bennett Helm [EMAIL PROTECTED] writes: I'm not sure what the status of this is now, but having just updating 1.6svn after a week of being away, I notice that moving by word stops at *both* word beginnings and word endings, whether moving forwards or backwards. Am I missing something? Did you install the updated lyxrc.dist? JMarc
Re: Proof of concept patch for bug 4812.
[EMAIL PROTECTED] wrote: rgheck [EMAIL PROTECTED] writes: Yes, I'm not at all sure how often we actually need to access a paragraph's layout. And I thought about converting LayoutList to a mapstring a while ago, but didn't do it. And index-based access is also worth a thought, too. That would be OK, as long as we only ever expanded the list of layouts at the end. AFAIR, we used to use layout names, but this was changed to using pointers after a profiling session from Lars. Well, you would know better than I. rh
Re: Proof of concept patch for bug 4812.
[EMAIL PROTECTED] wrote: rgheck [EMAIL PROTECTED] writes: Yes, I'm not at all sure how often we actually need to access a paragraph's layout. And I thought about converting LayoutList to a mapstring a while ago, but didn't do it. And index-based access is also worth a thought, too. That would be OK, as long as we only ever expanded the list of layouts at the end. AFAIR, we used to use layout names, but this was changed to using pointers after a profiling session from Lars. There is a risk for sure and a profiling session would be required if we switch to name based access. But the bottlenecks of years back may have disappeared now. Abdel.
Re: [Cvslog] r25500 - /lyx-devel/trunk/src/LyXAction.cpp
[EMAIL PROTECTED] wrote: Author: rgheck Date: Mon Jul 7 23:45:54 2008 New Revision: 25500 + To make this command enabled the layout file for the document + class you're using has to load the character styles. There are + a few contained in the Logical Markup module. You can also of + course create some yourself. \n it may be worth to write some documentation about already existing modules - what they are for, how they can be used. i didn't even noticed we already have such a neat module :) pavel
Re: Proof of concept patch for bug 4812.
There is a risk for sure and a profiling session would be required if we switch to name based access. But the bottlenecks of years back may have disappeared now. I do not see anything wrong with a pointer based system as long as we use a container that will not invalidate these pointers. std::vector is certainly not a good choice in this regard so I would recommend the use of std::list or std::map. Bo
Re: [Cvslog] r25500 - /lyx-devel/trunk/src/LyXAction.cpp
Pavel Sanda wrote: [EMAIL PROTECTED] wrote: Author: rgheck Date: Mon Jul 7 23:45:54 2008 New Revision: 25500 + To make this command enabled the layout file for the document + class you're using has to load the character styles. There are + a few contained in the Logical Markup module. You can also of + course create some yourself. \n it may be worth to write some documentation about already existing modules - what they are for, how they can be used. i didn't even noticed we already have such a neat module :) The intention was that they're documented in DocumentSettings itself. Of course, you have to look there to see what we have. We'll probably want a place on the wiki people can upload their own modules. rh
Re: Why do we need ImageMagick at all?
While I agree that ImageMagick is required for more specialized formats(*), we support already most common raster image formats thanks to Qt, without the need for ImageMagick; for ps/pdf/eps conversion to png, we should just use ghostscript directly. Why you might ask? Because we will remove one hard-dependency (at least for Mac and Windows) and we would also be free of ImageMagick bugs. One of the big things with LyX is, that you can use nearly every image format in your documents: http://imagemagick.org/script/formats.php Compare this to other word processors, that only supports JPG, PNG, GIF, anf TIFF. When I introduce LyX to newbies this feature is one of the killer features. Imagemagick has bugs as every program, but when I found a bug, I usually got it fixed in a few days. So that Imagemagick can have bugs should not be the reason to drop it as bugs in LyX are also no reason to use Word instead. Of course, when Qt supports image formats including, rotating, anialiasing, and cropping of whitespace, we could use Qt, in all other cases Imagemagick. regards Uwe
Re: [Cvslog] r25500 - /lyx-devel/trunk/src/LyXAction.cpp
rgheck wrote: it may be worth to write some documentation about already existing modules - what they are for, how they can be used. i didn't even noticed we already have such a neat module :) The intention was that they're documented in DocumentSettings itself. Of course, you have to look there to see what we have. some of the captions are bit puzzling. i will try to add some comments. pavel
Re: [1.6 bug] LyX's error dialog is broken
Uwe Stöhr schrieb: So the error dialog is currently useless. This is now bug 5007. regards Uwe
Re: [Cvslog] r25373 - in /lyx-devel/trunk/src: Paragraph.cpp Paragraph...
On Mon, Jul 7, 2008 at 5:39 PM, [EMAIL PROTECTED] wrote: Bennett Helm [EMAIL PROTECTED] writes: I'm not sure what the status of this is now, but having just updating 1.6svn after a week of being away, I notice that moving by word stops at *both* word beginnings and word endings, whether moving forwards or backwards. Am I missing something? Did you install the updated lyxrc.dist? Yes -- with \mac_like_word_movement true. I even moved aside my LyX user's folder just to make sure. Bennett
Re: Why do we need ImageMagick at all?
Abdelrazak Younes wrote: Hi, Question to image conversion experts: While I agree that ImageMagick is required for more specialized formats(*), we support already most common raster image formats thanks to Qt, without the need for ImageMagick; for ps/pdf/eps conversion to png, we My pet hate with LyX is when it attempts to guess the format. I would prefer it if it blanked out the image with a message like This format is unsupported, please add it to the converters section of the preferences. rather than attempting to guess. That way, I know what program is doing the conversion and what the parameters are. -- http://www.unmusic.co.uk Michael Reed -- technology, gender, and geek culture freelance writer
Re: Proof of concept patch for bug 4812.
Bo Peng wrote:
Dear all,
3. Use this expandable "unknown" layout for a document without valid layout.
} else {
// a warning will be given for unknown class
- setBaseClass(defaultBaseclass());
+ setBaseClass(unknownBaseclass());
Independently of the local layout problematic I think this last change
goes in the right direction; I never liked LyX to switch automatically
to whatever default layout, resulting in dataloss when the default
layout is article and the document has level one sections for example.
return classname;
}
The result:
1. A document without valid layout will be opened with a warning. (The same)
2. All layouts are usable, although they all look like "standard" (changed)
3. Save such a document will not lose data. The original layout name
will be used. (improved)
4. Another layout can be chosen from Document -> settings, if a
correct textclass is selected, all layouts will work fine. (improved,
because the current approach will change some unknown layouts to
standard.)
I think this is not enough. If the local layout is to be supported,
there should be a way to select this option in the document settings. If
you select this option, LyX should be able to reformat the document
dynamically if a proper local layout is found, or switch to the unknown
layout if not found.
The biggest problem with this patch is that because layout pointers
are used directly, LayoutList, which is std:;vector can not be
expanded dynamically. I change it to std::list to allow
dynamic growth of the "unknown" textclass but this may lead to
performance problems.
This is wrong IMHO, the vector should stay and you should just construct
this "unknown layout" together with all the others.
Any opinion is welcome.
You have mine. I guess this patch will bring back the debate around the
usefulness of the local layout stuff, I am no expert on this stuff so I
won't comment any further. But please no heated debate; as the 1.6
maintainer, the last decision is on Jûrgen's shoulder and, if he makes
one, it should be respected without any further discussion.
Abdel.
Why do we need ImageMagick at all?
Hi, Question to image conversion experts: While I agree that ImageMagick is required for more specialized formats(*), we support already most common raster image formats thanks to Qt, without the need for ImageMagick; for ps/pdf/eps conversion to png, we should just use ghostscript directly. Why you might ask? Because we will remove one hard-dependency (at least for Mac and Windows) and we would also be free of ImageMagick bugs. There's probably some use cases that I miss so that's why I thought I could ask... Abdel. * Even for those, using the original program is often (if not always) a better choice than using ImageMagick.
Re: Proof of concept patch for bug 4812.
Bo Peng wrote: > 1. A document without valid layout will be opened with a warning. (The > same) 2. All layouts are usable, although they all look like "standard" > (changed) 3. Save such a document will not lose data. The original layout > name will be used. (improved) > 4. Another layout can be chosen from Document -> settings, if a > correct textclass is selected, all layouts will work fine. (improved, > because the current approach will change some unknown layouts to > standard.) This looks like a sensible approach in general. Is the document class then not reset? So if I have ClassX, and this is not found, will LyX keep this ClassX unless I manually switch to another class? (This is the way it should be IMHO). Generally speaking, I'm glad to see that the hiding of the browse button finally triggered some action. Actually, this is what I intended with this rather rude step ;-) Jürgen
Re: Proof of concept patch for bug 4812.
>> 4. Another layout can be chosen from Document -> settings, if a >> correct textclass is selected, all layouts will work fine. (improved, >> because the current approach will change some unknown layouts to >> standard.) >> > > I think this is not enough. If the local layout is to be supported, there > should be a way to select this option in the document settings. If you > select this option, LyX should be able to reformat the document dynamically > if a proper local layout is found, or switch to the unknown layout if not > found. This is already the case. If we restore the browse button, users can browse a local layout and apply it. The biggest improvement is that, before this patch, layouts that are unknown to article.layout will be changed to standard, and will NOT be restored when a correct layout is selected. With this patch, the unknown layouts are kept although they look like standard. >> The biggest problem with this patch is that because layout pointers >> are used directly, LayoutList, which is std:;vector can not be >> expanded dynamically. I change it to std::list to allow >> dynamic growth of the "unknown" textclass but this may lead to >> performance problems. >> > > This is wrong IMHO, the vector should stay and you should just construct > this "unknown layout" together with all the others. I do not know how to do this. Layouts of other textclasses are loaded before layout pointers are assigned to paragraphs. This unknown textclass will grow when an unknown layout is encountered, which invalidates pointers of previously identified layouts if vector is used. > You have mine. I guess this patch will bring back the debate around the > usefulness of the local layout stuff, I am no expert on this stuff so I > won't comment any further. But please no heated debate; as the 1.6 > maintainer, the last decision is on Jûrgen's shoulder and, if he makes one, > it should be respected without any further discussion. As far as I am concerned, this bug has little, if any, to do with local layouts, and removing the local layout feature does not fix this problem at all. Bo
Re: Proof of concept patch for bug 4812.
> This looks like a sensible approach in general. Is the document class then > not reset? So if I have ClassX, and this is not found, will LyX keep this > ClassX unless I manually switch to another class? (This is the way it > should be IMHO). Yes. All layouts are kept, although the textclass is named "Unknown text class (unavailable)" in Document -> Settings. Users can edit and save this document as usual even if no valid layout is selected, although the document may not be compilable. The 'layout conversion' process only happens when another layout is selected from the textclass list, or from disk as a local layout. > Generally speaking, I'm glad to see that the hiding of the browse button > finally triggered some action. Actually, this is what I intended with this > rather rude step ;-) It worked. :-) Bo
Re: Why do we need ImageMagick at all?
Abdelrazak Younes wrote: > While I agree that ImageMagick is required for more specialized formats(*), > we support already most common raster image formats thanks to Qt, without > the need for ImageMagick; for ps/pdf/eps conversion to png, we should just > use ghostscript directly. > Why you might ask? Because we will remove one hard-dependency (at least for > Mac and Windows) and we would also be free of ImageMagick bugs. > > There's probably some use cases that I miss so that's why I thought I could > ask... i would ask whether we easily get some features like antialiasing. i guess we also use imagemagick for preparing pictures for latex generation, so it would lead to schizophrenic state that some pictures are converted via qt others via imagemagick, which is not good concept i think. but i dont know this part of code well. pavel
Re: Proof of concept patch for bug 4812.
Bo Peng wrote: The biggest problem with this patch is that because layout pointers are used directly, LayoutList, which is std:;vector can not be expanded dynamically. I change it to std::list to allow dynamic growth of the "unknown" textclass but this may lead to performance problems. This is wrong IMHO, the vector should stay and you should just construct this "unknown layout" together with all the others. I do not know how to do this. Layouts of other textclasses are loaded before layout pointers are assigned to paragraphs. This unknown textclass will grow when an unknown layout is encountered, which invalidates pointers of previously identified layouts if vector is used. This makes the use of layout pointers seem kind of fragile. Maybe we should just store the name of the layout instead, and then use TextClass::operator[] to find the layout when we need it. There may be other benefits to doing it that way, too. Another option: Does the unknown TextClass really have to have umpteen copies of the same thing? Can't it just pretend that it does? Lookup is via operator[]---and it could be tuned always to return the same thing, if we're dealing with the unknown TextClass. Richard
Re: Proof of concept patch for bug 4812.
rgheck wrote: Bo Peng wrote: The biggest problem with this patch is that because layout pointers are used directly, LayoutList, which is std:;vector can not be expanded dynamically. I change it to std::list to allow dynamic growth of the "unknown" textclass but this may lead to performance problems. This is wrong IMHO, the vector should stay and you should just construct this "unknown layout" together with all the others. I do not know how to do this. Layouts of other textclasses are loaded before layout pointers are assigned to paragraphs. This unknown textclass will grow when an unknown layout is encountered, which invalidates pointers of previously identified layouts if vector is used. This makes the use of layout pointers seem kind of fragile. Maybe we should just store the name of the layout instead, and then use TextClass::operator[] to find the layout when we need it. There may be other benefits to doing it that way, too. If there's no performance problem, that sounds good. But only if the changes are safe and not too intrusive. Abdel.
Re: Why do we need ImageMagick at all?
Abdelrazak Younes <[EMAIL PROTECTED]> writes: > Hi, > > Question to image conversion experts: > > While I agree that ImageMagick is required for more specialized > formats(*), we support already most common raster image formats thanks > to Qt, without the need for ImageMagick; for ps/pdf/eps conversion to > png, we should just use ghostscript directly. Well, you should make a list of all formats and see what conversions are or are not handled. AFAIK, imagemagick is used as backup solution in many cases. And there is nothing that really forces us to install or not IM. It is just a converter among others (or it should). JMarc
Re: Proof of concept patch for bug 4812.
"Bo Peng" <[EMAIL PROTECTED]> writes: > 1. A document without valid layout will be opened with a warning. (The same) > 2. All layouts are usable, although they all look like "standard" (changed) > 3. Save such a document will not lose data. The original layout name > will be used. (improved) > 4. Another layout can be chosen from Document -> settings, if a > correct textclass is selected, all layouts will work fine. (improved, > because the current approach will change some unknown layouts to > standard.) Although I did not check the details, this is something I have been wanting to do for a long time. JMarc
Re: Proof of concept patch for bug 4812.
>> This makes the use of layout pointers seem kind of fragile. Maybe we >> should just store the name of the layout instead, and then use >> TextClass::operator[] to find the layout when we need it. There may be other >> benefits to doing it that way, too. > > If there's no performance problem, that sounds good. But only if the changes > are safe and not too intrusive. The performance impact will be big because this layout pointer is used everywhere. Even storing layout index is better than storing their names. Anyway, my guess is that if layout pointers are used directly, using list or deque should not cause significant performance problem. JMarc may know more about this LayoutList stuff. Bo
Re: Proof of concept patch for bug 4812.
Bo Peng wrote: This makes the use of layout pointers seem kind of fragile. Maybe we should just store the name of the layout instead, and then use TextClass::operator[] to find the layout when we need it. There may be other benefits to doing it that way, too. If there's no performance problem, that sounds good. But only if the changes are safe and not too intrusive. The performance impact will be big because this layout pointer is used everywhere. Even storing layout index is better than storing their names. Using names would mean a map or a hash table (better) instead of a vector (which could lead to index based access). Maybe the perfomance impact would not be that big... one has to try. Anyway, my guess is that if layout pointers are used directly, using list or deque should not cause significant performance problem. JMarc may know more about this LayoutList stuff. The expert nowadays is Richard ;-) Abdel.
Re: Proof of concept patch for bug 4812.
>> The performance impact will be big because this layout pointer is used >> everywhere. Even storing layout index is better than storing their >> names. > > Using names would mean a map or a hash table (better) instead of a vector > (which could lead to index based access). Maybe the perfomance impact would > not be that big... one has to try. Actually, I was wondering why we need to define operator[name] instead of using std::map<> directly. Because insertion will not invalidate any pointer in a map, a map will work fine with the proposed patch. Whether or not replace Layout* with a name can be discussed later. Bo
Re: Proof of concept patch for bug 4812.
Abdelrazak Younes wrote: Bo Peng wrote: This makes the use of layout pointers seem kind of fragile. Maybe we should just store the name of the layout instead, and then use TextClass::operator[] to find the layout when we need it. There may be other benefits to doing it that way, too. If there's no performance problem, that sounds good. But only if the changes are safe and not too intrusive. The performance impact will be big because this layout pointer is used everywhere. Even storing layout index is better than storing their names. Using names would mean a map or a hash table (better) instead of a vector (which could lead to index based access). Maybe the perfomance impact would not be that big... one has to try. Yes, I'm not at all sure how often we actually need to access a paragraph's layout. And I thought about converting LayoutList to a map a while ago, but didn't do it. And index-based access is also worth a thought, too. That would be OK, as long as we only ever expanded the list of layouts at the end. But this would not be unintrusive now, I don't think. Anyway, my guess is that if layout pointers are used directly, using list or deque should not cause significant performance problem. JMarc may know more about this LayoutList stuff. The expert nowadays is Richard ;-) I don't have any problem with the list idea. As I said, the worry was just that pointers are starting to seem fragile. We've always used pointers, or something of the sort, I think, but maybe there is a better way. But certainly the (mislabeled) LayoutList (which has also been around forever, in one form or another) was never intended to be dynamic, and that's the root of the problem. rh
Re: [Cvslog] r25373 - in /lyx-devel/trunk/src: Paragraph.cpp Paragraph...
On Tue, Jun 24, 2008 at 9:25 AM, Bennett Helm <[EMAIL PROTECTED]> wrote: > On Tue, Jun 24, 2008 at 8:52 AM, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> > wrote: > >> > This is candidate for branch too. More problems remain in work >> > skipping, but eating insets was the worst. >> >> With this additional patch, word movement should be closer to what the >> mac does. It works through a lyxrc setting word_forward_goes_to_end >> (!) that is not associated to a UI element but can be set in >> lyxrc.dist. > > I'm not sure what the status of this is now, but having just updating 1.6svn after a week of being away, I notice that moving by word stops at *both* word beginnings and word endings, whether moving forwards or backwards. Am I missing something? Bennett
Re: python help needed
Jürgen Spitzmüller wrote: In order to fully fix bug 4927, we need to do some LaTeX->LyX conversion, because subfigure captions can contain LaTeX constructs such as \label. Currently, subcaptions with such constructs are simply eaten (i.e., dataloss). I think we should factor out the routines of convert_latexcommand_index to a helper function which is used by convert_latexcommand_index, convert_subfig and maybe others. I failed at doing this due to limited python knowledge. I'd appreciate if someone could jump in (and maybe also clean up my really ugly convert_subfig routine). I finally got around to doing this. I've also re-written the latex2lyx conversion routine so that it uses the unicodesymbols file. I'm not sure exactly what you had in mind for convert_subfig, as I don't know anything about figures, but perhaps this will let you do it now? rh
Re: Proof of concept patch for bug 4812.
rgheck <[EMAIL PROTECTED]> writes: > Yes, I'm not at all sure how often we actually need to access a > paragraph's layout. And I thought about converting LayoutList to a > map a while ago, but didn't do it. And index-based access is > also worth a thought, too. That would be OK, as long as we only ever > expanded the list of layouts at the end. AFAIR, we used to use layout names, but this was changed to using pointers after a profiling session from Lars. JMarc
Re: [Cvslog] r25373 - in /lyx-devel/trunk/src: Paragraph.cpp Paragraph...
"Bennett Helm" <[EMAIL PROTECTED]> writes: > I'm not sure what the status of this is now, but having just updating 1.6svn > after a week of being away, I notice that moving by word stops at *both* > word beginnings and word endings, whether moving forwards or backwards. Am I > missing something? Did you install the updated lyxrc.dist? JMarc
Re: Proof of concept patch for bug 4812.
[EMAIL PROTECTED] wrote: rgheck <[EMAIL PROTECTED]> writes: Yes, I'm not at all sure how often we actually need to access a paragraph's layout. And I thought about converting LayoutList to a map a while ago, but didn't do it. And index-based access is also worth a thought, too. That would be OK, as long as we only ever expanded the list of layouts at the end. AFAIR, we used to use layout names, but this was changed to using pointers after a profiling session from Lars. Well, you would know better than I. rh
Re: Proof of concept patch for bug 4812.
[EMAIL PROTECTED] wrote: rgheck <[EMAIL PROTECTED]> writes: Yes, I'm not at all sure how often we actually need to access a paragraph's layout. And I thought about converting LayoutList to a map a while ago, but didn't do it. And index-based access is also worth a thought, too. That would be OK, as long as we only ever expanded the list of layouts at the end. AFAIR, we used to use layout names, but this was changed to using pointers after a profiling session from Lars. There is a risk for sure and a profiling session would be required if we switch to name based access. But the bottlenecks of years back may have disappeared now. Abdel.
Re: [Cvslog] r25500 - /lyx-devel/trunk/src/LyXAction.cpp
[EMAIL PROTECTED] wrote: > Author: rgheck > Date: Mon Jul 7 23:45:54 2008 > New Revision: 25500 > + To make this command enabled the layout file for the document > + class you're using has to load the character styles. There are > + a few contained in the Logical Markup module. You can also of > + course create some yourself. \n it may be worth to write some documentation about already existing modules - what they are for, how they can be used. i didn't even noticed we already have such a neat module :) pavel
Re: Proof of concept patch for bug 4812.
> There is a risk for sure and a profiling session would be required if we > switch to name based access. But the bottlenecks of years back may have > disappeared now. I do not see anything wrong with a pointer based system as long as we use a container that will not invalidate these pointers. std::vector is certainly not a good choice in this regard so I would recommend the use of std::list or std::map. Bo
Re: [Cvslog] r25500 - /lyx-devel/trunk/src/LyXAction.cpp
Pavel Sanda wrote: [EMAIL PROTECTED] wrote: Author: rgheck Date: Mon Jul 7 23:45:54 2008 New Revision: 25500 + To make this command enabled the layout file for the document + class you're using has to load the character styles. There are + a few contained in the Logical Markup module. You can also of + course create some yourself. \n it may be worth to write some documentation about already existing modules - what they are for, how they can be used. i didn't even noticed we already have such a neat module :) The intention was that they're documented in Document>Settings itself. Of course, you have to look there to see what we have. We'll probably want a place on the wiki people can upload their own modules. rh
Re: Why do we need ImageMagick at all?
> While I agree that ImageMagick is required for more specialized formats(*), we support already > most common raster image formats thanks to Qt, without the need for ImageMagick; for ps/pdf/eps > conversion to png, we should just use ghostscript directly. Why you might ask? Because we will > remove one hard-dependency (at least for Mac and Windows) and we would also be free of ImageMagick > bugs. One of the big things with LyX is, that you can use nearly every image format in your documents: http://imagemagick.org/script/formats.php Compare this to other word processors, that only supports JPG, PNG, GIF, anf TIFF. When I introduce LyX to newbies this feature is one of the killer features. Imagemagick has bugs as every program, but when I found a bug, I usually got it fixed in a few days. So that Imagemagick can have bugs should not be the reason to drop it as bugs in LyX are also no reason to use Word instead. Of course, when Qt supports image formats including, rotating, anialiasing, and cropping of whitespace, we could use Qt, in all other cases Imagemagick. regards Uwe
Re: [Cvslog] r25500 - /lyx-devel/trunk/src/LyXAction.cpp
rgheck wrote: >> it may be worth to write some documentation about already existing modules >> - what >> they are for, how they can be used. i didn't even noticed we already have >> such a neat >> module :) >> >> > The intention was that they're documented in Document>Settings itself. Of > course, you have to look there to see what we have. some of the captions are bit puzzling. i will try to add some comments. pavel
Re: [1.6 bug] LyX's error dialog is broken
Uwe Stöhr schrieb: So the error dialog is currently useless. This is now bug 5007. regards Uwe
Re: [Cvslog] r25373 - in /lyx-devel/trunk/src: Paragraph.cpp Paragraph...
On Mon, Jul 7, 2008 at 5:39 PM, <[EMAIL PROTECTED]> wrote: > "Bennett Helm" <[EMAIL PROTECTED]> writes: > > I'm not sure what the status of this is now, but having just updating > 1.6svn > > after a week of being away, I notice that moving by word stops at *both* > > word beginnings and word endings, whether moving forwards or backwards. > Am I > > missing something? > > Did you install the updated lyxrc.dist? Yes -- with "\mac_like_word_movement true". I even moved aside my LyX user's folder just to make sure. Bennett
Re: Why do we need ImageMagick at all?
Abdelrazak Younes wrote: Hi, Question to image conversion experts: While I agree that ImageMagick is required for more specialized formats(*), we support already most common raster image formats thanks to Qt, without the need for ImageMagick; for ps/pdf/eps conversion to png, we My pet hate with LyX is when it attempts to guess the format. I would prefer it if it blanked out the image with a message like "This format is unsupported, please add it to the "converters" section of the preferences." rather than attempting to guess. That way, I know what program is doing the conversion and what the parameters are. -- http://www.unmusic.co.uk Michael Reed -- technology, gender, and geek culture freelance writer
