Re: Small poll - download speed of LyX installers

[Wolfgang Engelmann]

$ time wget 
'ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.3/lyx-2.3.0rc2/LyX-2.3.0rc2+qt5-x86_64-cocoa.dmg'


Am 16.02.2018 um 21:32 schrieb Pavel Sanda:

Pavel Sanda wrote:

Ok, updating

US(CA); 1.88MB/s;  academic network;M: UCSD(89.4MB/s), PL(6.83M/s), 
SA(8.85M/s), GR (6.36M/s)
US(OR); 808KB/s;   local ISP;   M: UCSD(2MB/s)
US(FL); 1.33MB/s;  residential LAN
US(TX); 20-100KB/s; hotel wifi; M: UCSD(2.89MB/s), SA(1.42MB/s)(!), 
GR(163KB/s)
US(MI); 1.14MB/s;  residential cable;   M: UCSD(11.6MB/s)
Ca(Qe): 242 KB/s;  academic network;M: UCSD(393 KB/s)
EU(Cz); 44.6MB/s;  academic network;M: UCSD(16.3MB/s), PL(25.5MB/s), 
SA(14.3MB/s), GR(12.0MB/s)
EU(Pt); 40.8MB/s;  academic network
EU(Pt); 4.26MB/s;  local ISP;
EU(De); 414KB/s;   local ISP;



Is this the latest poll result?
could I ask the members of the Linux User Group Tuebingen to try the 
poll? One reason is, that my result (EU(DE) 441kB/s) is rather annoying. 
I would like to see the differences in and around Tuebingen city.

What are the factors affecting the download speed?
Wolfgang

Re: Text output encodings

[Daniel Kian Mc Kiernan]

On 02/19/2018 04:43 PM, Daniel Kian Mc Kiernan wrote:

On 02/19/2018 10:44 AM, F M Salter wrote:


 To explain in more detail.    LyX uses utf-8.   utf-8 is 
standard on

most operating systems.

 RTF is obsolescent and is not a text file.

 If I insert utf-8 italic characters into a LyX file, the plain 
text

output contains italic characters.

 I wanted to know if there was a LyX method which would produce
italic utf-8 characters from emphasised text.

 If not, this would become a feature request.


You are confusing characters with glyphs.  The letter ‘a’ may be drawn 
many ways, but it is always the same character no matter how it is 
drawn; the distinct ways of drawing it are glyphs.


Unicode is supposed to distinguish characters from glyphs.  Its 
designers have done this imperfectly, sometimes making inexcusable 
mistakes, but they still basically do this.


There are no italics characters as such.  There are characters whose 
typical glyphs might seem to be italic, but these characters are not 
their glyphs, nor are the character with such typical glyphs the same 
characters as you take for the non-italicized versions.  There is no 
distinct _character_ italicized ‘a’, though there are distinct 
characters that are not ‘a’ but may look like italicized ‘a’ to you. A 
font file that rendered them without italicization would not violate 
the standards.


In theory, Unicode could have a combing character, such that following 
a character with the combining character would signal that the first 
character were in some way to be emphasized.  Right now, Unicode does 
not have this, and I doubt that it ever will, because of the struggles 
that would result over how many such characters there should be to 
support distinct forms of emphasis.


Now, you might suggest that LyX _fake_ it, identifying characters from 
one range that typically _look_ like italicizations of the characters 
found in standard European alphabets.  I'm not sure how well it could 
be implemented.  But, in any case, I don't think that this suggestion 
would be well received.  And, if you make it, then you need to be 
_very_ clear about what would provoke this device. (All emphasis? 
textit?)


I probably should add this point: If you have an interface that is 
indeed italicizing characters on demand, then it is using something 
other that Unicode as such to do it; any editor that italicizes some 
substrings and not others is actually using mark-up of some sort in 
its files.

Re: Text output encodings

[Mc Kiernan Daniel Kian]

On 02/19/2018 04:43 PM, Daniel Kian Mc Kiernan wrote:

On 02/19/2018 10:44 AM, F M Salter wrote:


 To explain in more detail.    LyX uses utf-8.   utf-8 is 
standard on

most operating systems.

 RTF is obsolescent and is not a text file.

 If I insert utf-8 italic characters into a LyX file, the plain 
text

output contains italic characters.

 I wanted to know if there was a LyX method which would produce
italic utf-8 characters from emphasised text.

 If not, this would become a feature request.


You are confusing characters with glyphs.  The letter ‘a’ may be drawn 
many ways, but it is always the same character no matter how it is 
drawn; the distinct ways of drawing it are glyphs.


Unicode is supposed to distinguish characters from glyphs.  Its 
designers have done this imperfectly, sometimes making inexcusable 
mistakes, but they still basically do this.


There are no italics characters as such.  There are characters whose 
typical glyphs might seem to be italic, but these characters are not 
their glyphs, nor are the character with such typical glyphs the same 
characters as you take for the non-italicized versions.  There is no 
distinct _character_ italicized ‘a’, though there are distinct 
characters that are not ‘a’ but may look like italicized ‘a’ to you. A 
font file that rendered them without italicization would not violate 
the standards.


In theory, Unicode could have a combing character, such that following 
a character with the combining character would signal that the first 
character were in some way to be emphasized.  Right now, Unicode does 
not have this, and I doubt that it ever will, because of the struggles 
that would result over how many such characters there should be to 
support distinct forms of emphasis.


Now, you might suggest that LyX _fake_ it, identifying characters from 
one range that typically _look_ like italicizations of the characters 
found in standard European alphabets.  I'm not sure how well it could 
be implemented.  But, in any case, I don't think that this suggestion 
would be well received.  And, if you make it, then you need to be 
_very_ clear about what would provoke this device. (All emphasis? 
textit?)


I probably should add this point: If you have an interface that is 
indeed italicizing characters on demand, then it is using something 
other that Unicode as such to do it; any editor that italicizes some 
substrings and not others is actually using mark-up of some sort in 
its files.

Re: LyX version 2.3.0rc2 available

[Liviu Andronic]

On 1/30/18, Scott Kostyshak  wrote:
> Public release of LyX version 2.3.0rc2
> 
>

Ubuntu packages are now available on the PPA:
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily


Regards,
Liviu


> We are proud to announce the second public release candidate of the new LyX
> 2.3
> series. This pre-release is meant for testing and should not be used for
> serious work. For curious users who would like to test in order to help
> catch
> bugs before the 2.3.0 release, please back up all of your documents and be
> prepared for the worst to happen. Most users (who desire a stable LyX
> version)
> should not use this pre-release.
>
> The 2.3 series has a rich set of new features compared to the current
> stable
> series. An overview of the new features can be found here:
>
>   https://wiki.lyx.org/LyX/NewInLyX23
>
> You can download LyX 2.3.0rc2 from ftp://ftp.lyx.org/pub/lyx/devel/.
>
> We appreciate your help in testing this pre-release!
>
> If a file from an earlier version of LyX is opened *and saved* with
> any version of 2.3.x, then the original file will automatically be
> backed up. The backup file will be found in the backup directory, if one
> is set under Tools> Preferences> Paths, or else in the same folder as
> the original file, if no backup directory is set. The filename of the
> backup file will be:
> ORIGNAME-lyxformat-NUM.lyx~
> where NUM is the LyX format number of the original file. In the case of
> 2.2.x file, this will be 508, but in the case of older files it will be
> different.
>
> The file lib/RELEASE-NOTES lists some known issues and problems compared
> to the current stable releases (LyX 2.2.x). We strongly recommend that
> packagers of LyX on various platforms and distributions read this file.
>
> As with any major release, this one comes with a lot of new features but
> also some bugs. If you think you have found a bug in LyX 2.3.0rc2, either
> email the LyX developers' mailing list (lyx-devel at lists.lyx.org),
> or open a bug report at https://www.lyx.org/trac/wiki/BugTrackerHome.
> Please specify if the behavior you are reporting is different from behavior
> in a previous LyX version.
>
> If you have trouble using LyX or have a question, consult the
> documentation that comes with LyX (under Help) and the LyX wiki, which you
> will find at https://wiki.lyx.org/. You can also send email to the LyX
> users'
> list (lyx-users at lists.lyx.org).
>
> The LyX team.
> https://www.lyx.org
>
>

Re: Cannot determine size of graphic

[Scott Kostyshak]

On Mon, Feb 19, 2018 at 07:13:29PM +, a...@andreashegenbart.de wrote:

> And now I tested it myself again and it works; my fault, sorry, I put the
> file in an different folder and then it lost the reference to the graphics.
> The notices lead me to the wrong error tracking. 
> Thanks a lot and beg your pardon.

No worries, Andreas! Thanks for keeping us updated. It's often the case
that making a minimal example helps figure out the root problem.

And thanks to Wolfgang for helping Andreas troubleshoot the issue.

Best,

Scott


signature.asc
Description: PGP signature

Re: Text output encodings

[Daniel Kian Mc Kiernan]

On 02/19/2018 10:44 AM, F M Salter wrote:


     To explain in more detail.    LyX uses utf-8.   utf-8 is standard on
most operating systems.

     RTF is obsolescent and is not a text file.

     If I insert utf-8 italic characters into a LyX file, the plain text
output contains italic characters.

     I wanted to know if there was a LyX method which would produce
italic utf-8 characters from emphasised text.

     If not, this would become a feature request.


You are confusing characters with glyphs.  The letter ‘a’ may be drawn 
many ways, but it is always the same character no matter how it is 
drawn; the distinct ways of drawing it are glyphs.


Unicode is supposed to distinguish characters from glyphs.  Its 
designers have done this imperfectly, sometimes making inexcusable 
mistakes, but they still basically do this.


There are no italics characters as such.  There are characters whose 
typical glyphs might seem to be italic, but these characters are not 
their glyphs, nor are the character with such typical glyphs the same 
characters as you take for the non-italicized versions.  There is no 
distinct _character_ italicized ‘a’, though there are distinct 
characters that are not ‘a’ but may look like italicized ‘a’ to you. 
A font file that rendered them without italicization would not violate 
the standards.


In theory, Unicode could have a combing character, such that following 
a character with the combining character would signal that the first 
character were in some way to be emphasized.  Right now, Unicode does 
not have this, and I doubt that it ever will, because of the struggles 
that would result over how many such characters there should be to 
support distinct forms of emphasis.


Now, you might suggest that LyX _fake_ it, identifying characters from 
one range that typically _look_ like italicizations of the characters 
found in standard European alphabets.  I'm not sure how well it could 
be implemented.  But, in any case, I don't think that this suggestion 
would be well received.  And, if you make it, then you need to be 
_very_ clear about what would provoke this device. (All emphasis? 
textit?)

Re: older lyx file (around 2009) gives error in lyx2.3.0beta1

[Richard Heck]

On 02/19/2018 10:40 AM, Jürgen Spitzmüller wrote:
> Am Montag, den 19.02.2018, 13:01 +0100 schrieb Kornel Benko:
>> OK, got it down to this:
> Excellent. Here is my analysis. 
>
> Since this is a very old document, it has "\layout Standard" in insets.
> Now as of format 315 (for LyX 1.6), we switched to "\begin_layout
> PlainLayout" and shortly afterwards "\begin_layout Plain Layout" inside
> insets. But we do not actually convert "Standard" to "Plain Layout"
> (probably since it is hard to predict where to do that and since we
> rely on LyX doing that anyway), so the insets keep having
> "\begin_layout Standard".
>
> Now the convert_separator routine (format 475) checks whether we are
> inside a text inset precisely by looking for "Plain Layout". This of
> course fails here, hence the separator is inserted (lyx_2_2.py:186ff.)
>
> I am not sure if there is an easy fix for this. The "real" fix would be
> to actually change Standard to PlainLayout in 315, but I suppose there
> were reasons for not doing that.

The one you mentioned, basically: Whether to use PlainLayout is set by
information in the layout files (ForcePlain), to which we do not have
access.

But you found a solution, so good!

Richard

AW: Cannot determine size of graphic

[ah]

-Ursprüngliche Nachricht-
Von: a...@andreashegenbart.de [mailto:a...@andreashegenbart.de] 
Gesendet: Montag, 19. Februar 2018 19:48
An: 'Wolfgang Engelmann' ;
'lyx-users@lists.lyx.org' 
Betreff: AW: Cannot determine size of graphic



-Ursprüngliche Nachricht-
Von: lyx-users@lists.lyx.org [mailto:lyx-users@lists.lyx.org] Im Auftrag von
Wolfgang Engelmann
Gesendet: Montag, 19. Februar 2018 19:19
An: lyx-users@lists.lyx.org
Betreff: Re: Cannot determine size of graphic



Am 19.02.2018 um 17:53 schrieb a...@andreashegenbart.de:
> Dear Scott,
>
> thanks a lot und I hope the attachment is what you mean:
>
> .lyx-file reduced
> and
> .txt-file
> with an extract of the assumed problematic commands.
>
> Best,
>
> Andreas
>
>
> -Ursprüngliche Nachricht-
> Von: lyx-users@lists.lyx.org [mailto:lyx-users@lists.lyx.org] Im 
> Auftrag von Scott Kostyshak
> Gesendet: Montag, 19. Februar 2018 00:55
> An: a...@andreashegenbart.de
> Cc: lyx-users@lists.lyx.org
> Betreff: Re: Cannot determine size of graphic
>
> On Sun, Feb 18, 2018 at 01:50:44PM +, a...@andreashegenbart.de wrote:
>> Dear lyx-user,
>>
>>   
>>
>> I got this LaTEx-Error “ Cannot determine size of graphic …” (pdf
>> attached) for all of the graphics in my document, after updating vom 
>> Lyx. 2.2.2 to Lyx 2.2.3, as well as updating miktex.
>>
>> Does anybody know, what to do?
>>
>> I didn´t found a comparable error in lyx-archive.
> Dear Andreas, could you please send a minimal example .lyx file (to 
> the list)? For more information, see here:
>
>https://wiki.lyx.org/FAQ/MinimalExample
>
> Best,
>
> Scott
Andreas,
I inserted a figure into your minimal example and I get a pdf output.
Could you send the figure which should be (or was) inserted?
Wolfgang

Dear Wolfgang,

You´ll find the figure attached. 
Best
Andreas

...

And now I tested it myself again and it works; my fault, sorry, I put the
file in an different folder and then it lost the reference to the graphics.
The notices lead me to the wrong error tracking. 
Thanks a lot and beg your pardon.

Andreas 

Re: Cannot determine size of graphic

[Wolfgang Engelmann]

Am 19.02.2018 um 19:47 schrieb a...@andreashegenbart.de:


-Ursprüngliche Nachricht-
Von: lyx-users@lists.lyx.org [mailto:lyx-users@lists.lyx.org] Im Auftrag von
Wolfgang Engelmann
Gesendet: Montag, 19. Februar 2018 19:19
An: lyx-users@lists.lyx.org
Betreff: Re: Cannot determine size of graphic



Am 19.02.2018 um 17:53 schrieb a...@andreashegenbart.de:

Dear Scott,

thanks a lot und I hope the attachment is what you mean:

.lyx-file reduced
and
.txt-file
with an extract of the assumed problematic commands.

Best,

Andreas


-Ursprüngliche Nachricht-
Von: lyx-users@lists.lyx.org [mailto:lyx-users@lists.lyx.org] Im
Auftrag von Scott Kostyshak
Gesendet: Montag, 19. Februar 2018 00:55
An: a...@andreashegenbart.de
Cc: lyx-users@lists.lyx.org
Betreff: Re: Cannot determine size of graphic

On Sun, Feb 18, 2018 at 01:50:44PM +, a...@andreashegenbart.de wrote:

Dear lyx-user,

   


I got this LaTEx-Error “ Cannot determine size of graphic …” (pdf
attached) for all of the graphics in my document, after updating vom
Lyx. 2.2.2 to Lyx 2.2.3, as well as updating miktex.

Does anybody know, what to do?

I didn´t found a comparable error in lyx-archive.

Dear Andreas, could you please send a minimal example .lyx file (to
the list)? For more information, see here:

https://wiki.lyx.org/FAQ/MinimalExample

Best,

Scott

Andreas,
I inserted a figure into your minimal example and I get a pdf output.
Could you send the figure which should be (or was) inserted?
Wolfgang

Dear Wolfgang,

You´ll find the figure attached.
Best
Andreas




Works her: I just inserted your fig and got the attached pdf file.
Wolfgang


DA_Test_graphics.pdf
Description: Adobe PDF document

AW: Cannot determine size of graphic

[ah]

-Ursprüngliche Nachricht-
Von: lyx-users@lists.lyx.org [mailto:lyx-users@lists.lyx.org] Im Auftrag von
Wolfgang Engelmann
Gesendet: Montag, 19. Februar 2018 19:19
An: lyx-users@lists.lyx.org
Betreff: Re: Cannot determine size of graphic



Am 19.02.2018 um 17:53 schrieb a...@andreashegenbart.de:
> Dear Scott,
>
> thanks a lot und I hope the attachment is what you mean:
>
> .lyx-file reduced
> and
> .txt-file
> with an extract of the assumed problematic commands.
>
> Best,
>
> Andreas
>
>
> -Ursprüngliche Nachricht-
> Von: lyx-users@lists.lyx.org [mailto:lyx-users@lists.lyx.org] Im 
> Auftrag von Scott Kostyshak
> Gesendet: Montag, 19. Februar 2018 00:55
> An: a...@andreashegenbart.de
> Cc: lyx-users@lists.lyx.org
> Betreff: Re: Cannot determine size of graphic
>
> On Sun, Feb 18, 2018 at 01:50:44PM +, a...@andreashegenbart.de wrote:
>> Dear lyx-user,
>>
>>   
>>
>> I got this LaTEx-Error “ Cannot determine size of graphic …” (pdf
>> attached) for all of the graphics in my document, after updating vom 
>> Lyx. 2.2.2 to Lyx 2.2.3, as well as updating miktex.
>>
>> Does anybody know, what to do?
>>
>> I didn´t found a comparable error in lyx-archive.
> Dear Andreas, could you please send a minimal example .lyx file (to 
> the list)? For more information, see here:
>
>https://wiki.lyx.org/FAQ/MinimalExample
>
> Best,
>
> Scott
Andreas,
I inserted a figure into your minimal example and I get a pdf output.
Could you send the figure which should be (or was) inserted?
Wolfgang

Dear Wolfgang,

You´ll find the figure attached. 
Best 
Andreas

Re: Text output encodings

[F M Salter]

On 19/02/18 07:55, F M Salter wrote:
> Hi
>
>     When plain text is used as output, emphasised text loses emphasis.
>
>     Is there any way by which text output may be specified with utf-8
> encoding?   Emphasis could then be maintained.
>
> Regards
>
> Frank Salter
>
...

...

    To explain in more detail.    LyX uses utf-8.   utf-8 is standard on
most operating systems.

    RTF is obsolescent and is not a text file.

    If I insert utf-8 italic characters into a LyX file, the plain text
output contains italic characters.

    I wanted to know if there was a LyX method which would produce
italic utf-8 characters from emphasised text.

    If not, this would become a feature request.

Regards
Frank Salter

Re: Cannot determine size of graphic

[Wolfgang Engelmann]

Am 19.02.2018 um 17:53 schrieb a...@andreashegenbart.de:

Dear Scott,

thanks a lot und I hope the attachment is what you mean:

.lyx-file reduced
and
.txt-file
with an extract of the assumed problematic commands.

Best,

Andreas


-Ursprüngliche Nachricht-
Von: lyx-users@lists.lyx.org [mailto:lyx-users@lists.lyx.org] Im Auftrag von
Scott Kostyshak
Gesendet: Montag, 19. Februar 2018 00:55
An: a...@andreashegenbart.de
Cc: lyx-users@lists.lyx.org
Betreff: Re: Cannot determine size of graphic

On Sun, Feb 18, 2018 at 01:50:44PM +, a...@andreashegenbart.de wrote:

Dear lyx-user,

  


I got this LaTEx-Error “ Cannot determine size of graphic …” (pdf
attached) for all of the graphics in my document, after updating vom
Lyx. 2.2.2 to Lyx 2.2.3, as well as updating miktex.

Does anybody know, what to do?

I didn´t found a comparable error in lyx-archive.

Dear Andreas, could you please send a minimal example .lyx file (to the
list)? For more information, see here:

   https://wiki.lyx.org/FAQ/MinimalExample

Best,

Scott

Andreas,
I inserted a figure into your minimal example and I get a pdf output.
Could you send the figure which should be (or was) inserted?
Wolfgang

AW: Cannot determine size of graphic

[ah]

Dear Scott,

thanks a lot und I hope the attachment is what you mean:

.lyx-file reduced 
and  
.txt-file 
with an extract of the assumed problematic commands. 

Best,

Andreas


-Ursprüngliche Nachricht-
Von: lyx-users@lists.lyx.org [mailto:lyx-users@lists.lyx.org] Im Auftrag von
Scott Kostyshak
Gesendet: Montag, 19. Februar 2018 00:55
An: a...@andreashegenbart.de
Cc: lyx-users@lists.lyx.org
Betreff: Re: Cannot determine size of graphic

On Sun, Feb 18, 2018 at 01:50:44PM +, a...@andreashegenbart.de wrote:
> Dear lyx-user,
> 
>  
> 
> I got this LaTEx-Error “ Cannot determine size of graphic …” (pdf 
> attached) for all of the graphics in my document, after updating vom 
> Lyx. 2.2.2 to Lyx 2.2.3, as well as updating miktex.
> 
> Does anybody know, what to do? 
> 
> I didn´t found a comparable error in lyx-archive.

Dear Andreas, could you please send a minimal example .lyx file (to the
list)? For more information, see here:

  https://wiki.lyx.org/FAQ/MinimalExample

Best,

Scott
This is pdfTeX, Version 3.14159265-2.6-1.40.18 (MiKTeX 2.9.6600) (preloaded 
format=pdflatex 2018.2.14)  19 FEB 2018 17:26
entering extended mode
**./DA_Test_graphics.tex
(DA_Test_graphics.tex
LaTeX2e <2017-04-15>
Babel <3.17> and hyphenation patterns for 76 language(s) loaded.

...

("C:\Program Files (x86)\MiKTeX 2.9\tex\generic\oberdiek\etexcmds.sty"
Package: etexcmds 2016/05/16 v1.6 Avoid name clashes with e-TeX commands (HO)
("C:\Program Files (x86)\MiKTeX 2.9\tex\generic\oberdiek\ifluatex.sty"
Package: ifluatex 2016/05/16 v1.4 Provides the ifluatex switch (HO)
Package ifluatex Info: LuaTeX not detected.
)
Package etexcmds Info: Could not find \expanded.
(etexcmds) That can mean that you are not using pdfTeX 1.50 or
(etexcmds) that some package has redefined \expanded.
(etexcmds) In the latter case, load this package earlier.
))) ("C:\Program Files (x86)\MiKTeX 2.9\tex\generic\oberdiek\pdftexcmds.sty"
Package: pdftexcmds 2018/01/21 v0.26 Utility functions of pdfTeX for LuaTeX (HO
)
Package pdftexcmds Info: LuaTeX not detected.
Package pdftexcmds Info: \pdf@primitive is available.
Package pdftexcmds Info: \pdf@ifprimitive is available.
Package pdftexcmds Info: \pdfdraftmode found.
)
Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
38.
Package grfext Info: Graphics extension search list:
(grfext) [.pdf,.png,.jpg,.mps,.jpeg,.jbig2,.jb2,.PDF,.PNG,.JPG,.JPE
G,.JBIG2,.JB2,.eps]
(grfext) \AppendGraphicsExtensions on input line 456.
)
Package pdftex.def Info: Option `bb' equivalent to `viewport' with pdftex drive
r on input line 37.

! LaTeX Error: Cannot determine size of graphic in Abbildungen/Dienstleistung/D
ienstleistungsdyade.jpg (no size specified).

See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
 ...  
  
l.37 ...n/Dienstleistung/Dienstleistungsdyade.jpg}
  
Try typingto proceed.
If that doesn't work, type  X   to quit.

LaTeX Font Info:Try loading font information for T1+cmtt on input line 37.
("C:\Program Files (x86)\MiKTeX 2.9\tex\latex\base\t1cmtt.fd"
File: t1cmtt.fd 2014/09/29 v2.5h Standard LaTeX font definitions
)
Overfull \hbox (14.22633pt too wide) in paragraph at lines 37--38
[][] 
 []


Underfull \hbox (badness 1) in paragraph at lines 40--40
[][]\T1/ptm/m/n/12 Dienstleistungsdyade
 []

[1

{C:/Users/admin/AppData/Local/MiKTeX/2.9/pdftex/config/pdftex.map}] (DA_Test_gr
aphics.aux)

LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.
 ) 
Here is how much of TeX's memory you used:
 5854 strings out of 493299
 92386 string characters out of 3136121
 255224 words of memory out of 300
 9321 multiletter control sequences out of 15000+20
 9381 words of font info for 20 fonts, out of 300 for 9000
 1141 hyphenation exceptions out of 8191
 51i,6n,51p,8850b,239s stack positions out of 5000i,500n,1p,20b,5s
{C:/Program Files (x86)/MiKTeX 2.9/fonts/enc/dvips/base/8r.enc}{C:/Program Fi
les (x86)/MiKTeX 2.9/fonts/enc/dvips/cm-super/cm-super-t1.enc}
Output written on DA_Test_graphics.pdf (1 page, 40984 bytes).
PDF statistics:
 16 PDF objects out of 1000 (max. 8388607)
 0 named destinations out of 1000 (max. 50)
 1 words of extra memory for PDF output out of 1 (max. 1000)



DA_Test_graphics.lyx
Description: application/lyx

Re: older lyx file (around 2009) gives error in lyx2.3.0beta1

[Kornel Benko]

Am Montag, 19. Februar 2018 16:58:51 CET schrieb Jürgen Spitzmüller 
:
> Am Montag, den 19.02.2018, 16:40 +0100 schrieb Jürgen Spitzmüller:
> > I am not sure if there is an easy fix for this. The "real" fix would
> > be
> > to actually change Standard to PlainLayout in 315, but I suppose
> > there
> > were reasons for not doing that. I am not sure if the check in
> > convert_separator can be adapted to cover these old cases.
> 
> I found a solution: Check whether there is and inset end before current
> layout begin and previous layout end. See attached patch.
> 
> Jürgen
> 
> > Jürgen
> > 

Yes, works for me. +1 for commit.

Kornel

Re: older lyx file (around 2009) gives error in lyx2.3.0beta1

[Jürgen Spitzmüller]

Am Montag, den 19.02.2018, 16:40 +0100 schrieb Jürgen Spitzmüller:
> I am not sure if there is an easy fix for this. The "real" fix would
> be
> to actually change Standard to PlainLayout in 315, but I suppose
> there
> were reasons for not doing that. I am not sure if the check in
> convert_separator can be adapted to cover these old cases.

I found a solution: Check whether there is and inset end before current
layout begin and previous layout end. See attached patch.

Jürgen

> 
> Jürgen
> 
> > 
> > Korneldiff --git a/lib/lyx2lyx/lyx_2_2.py b/lib/lyx2lyx/lyx_2_2.py
index cb1731304e..2dd749ad78 100644
--- a/lib/lyx2lyx/lyx_2_2.py
+++ b/lib/lyx2lyx/lyx_2_2.py
@@ -189,6 +189,10 @@ def convert_separator(document):
 
 j = find_token_backwards(document.body, "\\end_layout", i-1)
 if j != -1:
+n = find_token(document.body, "\\end_inset", j, lay[1])
+if n != -1:
+i = i + 1
+continue
 lay = get_containing_layout(document.body, j-1)
 if lay != False and lay[0] == "Standard" \
and find_token(document.body, "\\align", lay[1], lay[2]) == -1 \


signature.asc
Description: This is a digitally signed message part

Re: older lyx file (around 2009) gives error in lyx2.3.0beta1

[Jürgen Spitzmüller]

Am Montag, den 19.02.2018, 13:01 +0100 schrieb Kornel Benko:
> OK, got it down to this:

Excellent. Here is my analysis. 

Since this is a very old document, it has "\layout Standard" in insets.
Now as of format 315 (for LyX 1.6), we switched to "\begin_layout
PlainLayout" and shortly afterwards "\begin_layout Plain Layout" inside
insets. But we do not actually convert "Standard" to "Plain Layout"
(probably since it is hard to predict where to do that and since we
rely on LyX doing that anyway), so the insets keep having
"\begin_layout Standard".

Now the convert_separator routine (format 475) checks whether we are
inside a text inset precisely by looking for "Plain Layout". This of
course fails here, hence the separator is inserted (lyx_2_2.py:186ff.)

I am not sure if there is an easy fix for this. The "real" fix would be
to actually change Standard to PlainLayout in 315, but I suppose there
were reasons for not doing that. I am not sure if the check in
convert_separator can be adapted to cover these old cases.

Jürgen

> 
>   Kornel
> 

signature.asc
Description: This is a digitally signed message part

Re: older lyx file (around 2009) gives error in lyx2.3.0beta1

[Kornel Benko]

Am Montag, 19. Februar 2018 10:54:25 CET schrieb Jürgen Spitzmüller 
:
> Am Montag, den 19.02.2018, 10:35 +0100 schrieb Wolfgang Engelmann:
> > Kornel, Jürgen, I went back to an older lyx file (another book) and
> > found that this can not be processed by lyx2.3.0.beta1.
> > I could send the old lyx file (1999) which was:
> > #This file was created by  Thu Sep 30 18:13:25 1999
> > #LyX 1.0 (C) 1995-1999 Matthias Ettrich and the LyX Team
> > \lyxformat 2.15
> > 
> > I found the curled arrow sign behind the inserted fig e1f2.eps and
> > in
> > the index
> > Science Citation Index
> > 
> > I could send the exported lyx2.3.0.beta1 tex file to you privately
> > (because of its length and since it is uninteresting for the user
> > group
> > members. If you need also the original lyx file too (I think that is
> > the
> > important one for you), let me know.
> 
> Please send the _original_ LyX file (the old one before importing to
> LYX 2.3beta) via PM.
> 
> Jürgen
> 
> > Wolfgang

OK, got it down to this:

Kornel



ren99i.lyx
Description: application/lyx

Re: Text output encodings

[Mc Kiernan Daniel Kian]

On 02/19/2018 02:25 AM, F M Salter wrote:

On 19/02/18 08:06, Daniel Kian Mc Kiernan wrote:


The very definition of “plain text” precludes what you're hoping 
toget. The closest thing of which I know to what you want is 
RTF(rich-text format)



Plain text is the export option offered by LyX.
There is no RTF option!


First, if that were simply true, it wouldn't change the point that 
plain text simply does not have italics, boldface, underlining,  
And that was my essential point.


Second, when last I knew, users could configure LyX to work with 
LaTeX2rtf on some OSs (Linux, Mac OS X, and Windows).  How this 
configuration is effected varies with OS.  If you really want to 
export to RTF, google “LaTeX2rtf site:lyx.org”.


But, since I don't know what your ultimate objective be, I don't know 
whether converting to RTF would really get you closer, or just send 
you on a goose-chase.

Re: quantifiers in lyx

[mike]

On 18/02/2018 22:12, Richard Heck wrote:

On 02/18/2018 04:48 PM, Jean-Marc Lasgouttes wrote:

Le 18/02/2018 à 13:37, mike a écrit :

Dear list

Is there a way to get quantifiers without ERT?

Hello,

What kind of quantifiers do you have in mind?

Probably he means logical quantifiers, like ∀ and ∃.

These can be entered in math mode. Just hit Ctrl-M to enter math mode, and
then you can enter them as LaTeX: \forall, \exists, etc. Or you can
choose them
from the math toolbar that pops up. They are on the menu with the upside
down Δ.

Richard




Thanks Jean-Marc and Richard.  Problem solved.

Best regards

Mike

--
I *AM* a unique and special snowflake

Re: Text output encodings

[Pavel Sanda]

F M Salter wrote:
> On 19/02/18 08:06, Daniel Kian Mc Kiernan wrote:
> > The very definition of ???plain text??? precludes what you're hoping
> > to get. The closest thing of which I know to what you want is
> > RTF (rich-text format)
> >
> Plain text is the export option offered by LyX.
> There is no RTF option!

Try installing latex2rtf first (http://www.lyx.org/AdditionalSoftware).
Pavel

Re: Text output encodings

[F M Salter]

On 19/02/18 08:06, Daniel Kian Mc Kiernan wrote:
> The very definition of “plain text” precludes what you're hoping
> to get. The closest thing of which I know to what you want is
> RTF (rich-text format)
>
Plain text is the export option offered by LyX.
There is no RTF option!

Regards
Frank Salter

Re: older lyx file (around 2009) gives error in lyx2.3.0beta1

[Jürgen Spitzmüller]

Am Montag, den 19.02.2018, 10:35 +0100 schrieb Wolfgang Engelmann:
> Kornel, Jürgen, I went back to an older lyx file (another book) and 
> found that this can not be processed by lyx2.3.0.beta1.
> I could send the old lyx file (1999) which was:
> #This file was created by  Thu Sep 30 18:13:25 1999
> #LyX 1.0 (C) 1995-1999 Matthias Ettrich and the LyX Team
> \lyxformat 2.15
> 
> I found the curled arrow sign behind the inserted fig e1f2.eps and
> in 
> the index
> Science Citation Index
> 
> I could send the exported lyx2.3.0.beta1 tex file to you privately 
> (because of its length and since it is uninteresting for the user
> group 
> members. If you need also the original lyx file too (I think that is
> the 
> important one for you), let me know.

Please send the _original_ LyX file (the old one before importing to
LYX 2.3beta) via PM.

Jürgen

> 
> Wolfgang

signature.asc
Description: This is a digitally signed message part

Re: older lyx file (around 2009) gives error in lyx2.3.0beta1

[Kornel Benko]

Am Montag, 19. Februar 2018 10:35:17 CET schrieb Wolfgang Engelmann 
:
> Am 19.02.2018 um 09:42 schrieb Jürgen Spitzmüller:
> > Am Montag, den 19.02.2018, 09:28 +0100 schrieb Kornel Benko:
> >> OK, created MWE.
> > 
> > But this MWE already contains the latexpar separator. And the crucial
> > question is how this was added in the first place.
> > 
> > Jürgen
> > 
> >>Kornel
> 
> Kornel, Jürgen, I went back to an older lyx file (another book) and
> found that this can not be processed by lyx2.3.0.beta1.
> I could send the old lyx file (1999) which was:
> #This file was created by  Thu Sep 30 18:13:25 1999
> #LyX 1.0 (C) 1995-1999 Matthias Ettrich and the LyX Team
> \lyxformat 2.15
> 
> I found the curled arrow sign behind the inserted fig e1f2.eps and in
> the index
> Science Citation Index
> 
> I could send the exported lyx2.3.0.beta1 tex file to you privately
> (because of its length and since it is uninteresting for the user group
> members. If you need also the original lyx file too (I think that is the
> important one for you), let me know.
> 
> Wolfgang

I think, only the original file is important.

Kornel

Re: older lyx file (around 2009) gives error in lyx2.3.0beta1

[Wolfgang Engelmann]

Am 19.02.2018 um 09:42 schrieb Jürgen Spitzmüller:

Am Montag, den 19.02.2018, 09:28 +0100 schrieb Kornel Benko:

OK, created MWE.

But this MWE already contains the latexpar separator. And the crucial
question is how this was added in the first place.

Jürgen


Kornel
Kornel, Jürgen, I went back to an older lyx file (another book) and 
found that this can not be processed by lyx2.3.0.beta1.

I could send the old lyx file (1999) which was:
#This file was created by  Thu Sep 30 18:13:25 1999
#LyX 1.0 (C) 1995-1999 Matthias Ettrich and the LyX Team
\lyxformat 2.15

I found the curled arrow sign behind the inserted fig e1f2.eps and in 
the index

Science Citation Index

I could send the exported lyx2.3.0.beta1 tex file to you privately 
(because of its length and since it is uninteresting for the user group 
members. If you need also the original lyx file too (I think that is the 
important one for you), let me know.


Wolfgang

Re: older lyx file (around 2009) gives error in lyx2.3.0beta1

[Jürgen Spitzmüller]

Am Montag, den 19.02.2018, 09:28 +0100 schrieb Kornel Benko:
> OK, created MWE.

But this MWE already contains the latexpar separator. And the crucial
question is how this was added in the first place.

Jürgen

> 
>   Kornel

signature.asc
Description: This is a digitally signed message part

Re: older lyx file (around 2009) gives error in lyx2.3.0beta1

[Kornel Benko]

Am Montag, 19. Februar 2018 08:38:44 CET schrieb Wolfgang Engelmann 
:
> Is this sufficient?


OK, created MWE.

Kornel

test2.lyx
Description: application/lyx

Re: older lyx file (around 2009) gives error in lyx2.3.0beta1

[Jürgen Spitzmüller]

Am Montag, den 19.02.2018, 07:46 +0100 schrieb Wolfgang Engelmann:
> The ORIGINAL (old) file:
> 
> \begin_layout Standard
> If you look at White Clover
> \begin_inset Index idx
> status collapsed
> 
> \begin_layout Plain Layout
> White Clover
> \begin_inset Separator latexpar
> \end_inset

So the separator (the problematic inset) is already in the original
file!

Are you sure you don't already get the error with LyX 2.2?

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: Text output encodings

[Daniel Kian Mc Kiernan]

The very definition of “plain text” precludes what you're hoping to 
get.  The closest thing of which I know to what you want is RTF 
(rich-text format).


On 02/18/2018 11:55 PM, F M Salter wrote:


Hi

     When plain text is used as output, emphasised text loses emphasis.

     Is there any way by which text output may be specified with utf-8
encoding?   Emphasis could then be maintained.

Regards

Frank Salter