Re: Graphics Conversion
On 1/27/24 12:37, Pavel Sanda wrote: On Sat, Jan 27, 2024 at 05:30:19PM +0100, didiergab...@free.fr wrote: With this second version the pdf preview is also perfect ! Good, committed as 7eb5003a81ab. Will be part of RC2, for your convenience you can leave the new configure.py within your local RC1 installation... Good work, Pavel. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Graphics Conversion
On Sat, Jan 27, 2024 at 05:30:19PM +0100, didiergab...@free.fr wrote: > With this second version the pdf preview is also perfect ! Good, committed as 7eb5003a81ab. Will be part of RC2, for your convenience you can leave the new configure.py within your local RC1 installation... Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Graphics Conversion
On Sat, Jan 27, 2024 at 06:05:02PM +0100, didiergab...@free.fr wrote: > After setting up this version of the ???configure.py??? script I no longer > find any trace of the file converter: > PDF (graphic) ???> PNG with the command: > ???pdftoppm -r 72 -png -singlefile $$i > $$o??? > > Can you confirm that this is normal? (I tell myself that I may have clicked > on the ???remove??? button by mistake???) Yes, this will be new normal on windows (you are actually back on 2.3 default). For some reason pdftoppm is broken on windows. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Graphics Conversion
After setting up this version of the “configure.py” script I no longer find any trace of the file converter: PDF (graphic) —> PNG with the command: “pdftoppm -r 72 -png -singlefile $$i > $$o” Can you confirm that this is normal? (I tell myself that I may have clicked on the “remove” button by mistake…) - Mail original - | With this second version the pdf preview is also perfect ! | - Mail original - | | On Sat, Jan 27, 2024 at 02:29:15PM +0100, Pavel Sanda wrote: | | | > On Sat, Jan 27, 2024 at 01:43:02PM +0100, didiergab...@free.fr | | > wrote: | | | > > It's perfect ! See for yourself??? | | | > | | | > Good. I will need to prepare more generic patch for you to test. | | | Didier, please test the generic version of configure.py. | | | The same thing to test: | | | 1) Remove all files in cache (do this for any re-test) | | | 2) Take configure.py attached to this email and replace it by the | | one | | you found in Resources. | | | 3) Launch lyx & reconfigure via Tools->Reconfigure. | | | 4) Close lyx and launch it again, open your problematic example. | | | I will commit this version to 2.4 if it works. | | | Pavel | -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Graphics Conversion
With this second version the pdf preview is also perfect ! - Mail original - | On Sat, Jan 27, 2024 at 02:29:15PM +0100, Pavel Sanda wrote: | > On Sat, Jan 27, 2024 at 01:43:02PM +0100, didiergab...@free.fr | > wrote: | > > It's perfect ! See for yourself??? | > | > Good. I will need to prepare more generic patch for you to test. | Didier, please test the generic version of configure.py. | The same thing to test: | 1) Remove all files in cache (do this for any re-test) | 2) Take configure.py attached to this email and replace it by the one | you found in Resources. | 3) Launch lyx & reconfigure via Tools->Reconfigure. | 4) Close lyx and launch it again, open your problematic example. | I will commit this version to 2.4 if it works. | Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Graphics Conversion
On Sat, Jan 27, 2024 at 02:29:15PM +0100, Pavel Sanda wrote:
> On Sat, Jan 27, 2024 at 01:43:02PM +0100, didiergab...@free.fr wrote:
> > It's perfect ! See for yourself???
>
> Good. I will need to prepare more generic patch for you to test.
Didier, please test the generic version of configure.py.
The same thing to test:
1) Remove all files in cache (do this for any re-test)
2) Take configure.py attached to this email and replace it by the one you found
in Resources.
3) Launch lyx & reconfigure via Tools->Reconfigure.
4) Close lyx and launch it again, open your problematic example.
I will commit this version to 2.4 if it works.
Pavel
#! /usr/bin/python3
# -*- coding: utf-8 -*-
#
# file configure.py
# This file is part of LyX, the document processor.
# Licence details can be found in the file COPYING.
# \author Bo Peng
# Full author contact details are available in file CREDITS.
from __future__ import print_function
import glob, logging, os, errno, re, shutil, subprocess, sys, stat
if sys.version_info[0] < 3:
import codecs
open = codecs.open
# set up logging
logging.basicConfig(level = logging.DEBUG,
format = '%(levelname)s: %(message)s', # ignore application name
filename = 'configure.log',
filemode = 'w')
#
# Add a handler to log to console
console = logging.StreamHandler()
console.setLevel(logging.INFO) # the console only print out general information
formatter = logging.Formatter('%(message)s') # only print out the message itself
console.setFormatter(formatter)
logger = logging.getLogger('LyX')
logger.addHandler(console)
def quoteIfSpace(name):
" utility function: quote name if it contains spaces "
if ' ' in name:
return '"' + name + '"'
else:
return name
def writeToFile(filename, lines, append = False):
" utility function: write or append lines to filename "
if append:
file = open(filename, 'a')
else:
file = open(filename, 'w')
file.write(lines)
file.close()
def addToRC(lines):
''' utility function: shortcut for appending lines to outfile
add newline at the end of lines.
'''
if lines.strip():
writeToFile(outfile, lines + '\n', append = True)
logger.debug('Add to RC:\n' + lines + '\n\n')
def removeFiles(filenames):
'''utility function: 'rm -f'
ignore errors when file does not exist, or is a directory.
'''
for file in filenames:
try:
os.remove(file)
logger.debug('Removing file %s' % file)
except OSError as e:
if e.errno == errno.ENOENT: # no such file or directory
logger.debug('No need to remove file %s (it does not exists)' %
file)
elif e.errno == errno.EISDIR: # is a directory
logger.debug('Failed to remove file %s (it is a directory)' %
file)
else:
logger.debug('Failed to remove file %s' % file)
pass
def cmdOutput(cmd, asynchronous = False):
'''utility function: run a command and get its output as a string
cmd: command to run
asynchronous: if False, return whole output as a string, otherwise
return the stdout handle from which the output can be
read (the caller is then responsible for closing it)
'''
if os.name == 'nt':
b = False
if sys.version_info[0] < 3:
cmd = 'cmd /d /c pushd ' + shortPath(os.getcwdu()) + '&' + cmd
else:
cmd = 'cmd /d /c pushd ' + shortPath(os.getcwd()) + '&' + cmd
else:
b = True
pipe = subprocess.Popen(cmd, shell=b, close_fds=b, stdin=subprocess.PIPE,
stdout=subprocess.PIPE, universal_newlines=True)
pipe.stdin.close()
if asynchronous:
return pipe.stdout
output = pipe.stdout.read()
pipe.stdout.close()
return output.strip()
def shortPath(path):
''' On Windows, return the short version of "path" if possible '''
if os.name == 'nt':
from ctypes import windll, create_unicode_buffer
GetShortPathName = windll.kernel32.GetShortPathNameW
shortlen = GetShortPathName(path, 0, 0)
shortpath = create_unicode_buffer(shortlen)
if GetShortPathName(path, shortpath, shortlen):
return shortpath.value
return path
def setEnviron():
''' I do not really know why this is useful, but we might as well keep it.
NLS nuisances.
Only set these to C if already set. These must not be set
unconditionally
because not all systems understand e.g. LANG=C (notably SCO).
Fixing LC_MESSAGES prevents Solaris sh from translating var values in
set!
Non-C LC_CTYPE values break the ctype check.
'''
os.environ['LANG'] = os.getenv('LANG', 'C')
os.environ['LC'] = os.getenv('LC_ALL', 'C')
os.environ['LC_MESSAGE'] = os.getenv('LC_MESSAGE', 'C')
os.environ['LC_CTYPE'] = os.getenv('LC_CTYPE', 'C')
def copy_tree(src, dst,
Re: Graphics Conversion
On Sat, Jan 27, 2024 at 01:43:02PM +0100, didiergab...@free.fr wrote: > It's perfect ! See for yourself??? Good. I will need to prepare more generic patch for you to test. Stay tuned, Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Graphics Conversion
ps : But be careful, I'll come back with another question in a few minutes... On the list of simple users... For a story about the background color of an svg graphic... ;o) - Mail original - | It's perfect ! See for yourself… | Thank’s | Thank you so much ! | ps: | - Mail original - | | On Sat, Jan 27, 2024 at 01:16:39PM +0100, didiergab...@free.fr | | wrote: | | | > I see where the ???cache??? folder is located in my user | | > directory | | > here : | | | > | | | > C:\Users\Didier\AppData\Roaming\LyX2.4\cache | | | > | | | > And I just spotted the configure.py file here: | | | > | | | > C:\Users\Didier\AppData\Local\Programs\LyX 2.4\Resources | | | > | | | > So ok ? | | | Good, so let's try first iteration: | | | 1) Remove all files in cache (do this for any re-test) | | | 2) Take configure.py attached to this email and replace it by the | | one | | you found in Resources. | | | 3) Launch lyx & reconfigure via Tools->Reconfigure. | | | 4) Close lyx and launch it again, open your problematic example. | | | Any better? | | | Pavel | -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Graphics Conversion
On Sat, Jan 27, 2024 at 01:16:39PM +0100, didiergab...@free.fr wrote:
> I see where the ???cache??? folder is located in my user directory here :
>
> C:\Users\Didier\AppData\Roaming\LyX2.4\cache
>
> And I just spotted the configure.py file here:
>
> C:\Users\Didier\AppData\Local\Programs\LyX 2.4\Resources
>
> So ok ?
Good, so let's try first iteration:
1) Remove all files in cache (do this for any re-test)
2) Take configure.py attached to this email and replace it by the one you found
in Resources.
3) Launch lyx & reconfigure via Tools->Reconfigure.
4) Close lyx and launch it again, open your problematic example.
Any better?
Pavel
#! /usr/bin/python3
# -*- coding: utf-8 -*-
#
# file configure.py
# This file is part of LyX, the document processor.
# Licence details can be found in the file COPYING.
# \author Bo Peng
# Full author contact details are available in file CREDITS.
from __future__ import print_function
import glob, logging, os, errno, re, shutil, subprocess, sys, stat
if sys.version_info[0] < 3:
import codecs
open = codecs.open
# set up logging
logging.basicConfig(level = logging.DEBUG,
format = '%(levelname)s: %(message)s', # ignore application name
filename = 'configure.log',
filemode = 'w')
#
# Add a handler to log to console
console = logging.StreamHandler()
console.setLevel(logging.INFO) # the console only print out general information
formatter = logging.Formatter('%(message)s') # only print out the message itself
console.setFormatter(formatter)
logger = logging.getLogger('LyX')
logger.addHandler(console)
def quoteIfSpace(name):
" utility function: quote name if it contains spaces "
if ' ' in name:
return '"' + name + '"'
else:
return name
def writeToFile(filename, lines, append = False):
" utility function: write or append lines to filename "
if append:
file = open(filename, 'a')
else:
file = open(filename, 'w')
file.write(lines)
file.close()
def addToRC(lines):
''' utility function: shortcut for appending lines to outfile
add newline at the end of lines.
'''
if lines.strip():
writeToFile(outfile, lines + '\n', append = True)
logger.debug('Add to RC:\n' + lines + '\n\n')
def removeFiles(filenames):
'''utility function: 'rm -f'
ignore errors when file does not exist, or is a directory.
'''
for file in filenames:
try:
os.remove(file)
logger.debug('Removing file %s' % file)
except OSError as e:
if e.errno == errno.ENOENT: # no such file or directory
logger.debug('No need to remove file %s (it does not exists)' % file)
elif e.errno == errno.EISDIR: # is a directory
logger.debug('Failed to remove file %s (it is a directory)' % file)
else:
logger.debug('Failed to remove file %s' % file)
pass
def cmdOutput(cmd, asynchronous = False):
'''utility function: run a command and get its output as a string
cmd: command to run
asynchronous: if False, return whole output as a string, otherwise
return the stdout handle from which the output can be
read (the caller is then responsible for closing it)
'''
if os.name == 'nt':
b = False
if sys.version_info[0] < 3:
cmd = 'cmd /d /c pushd ' + shortPath(os.getcwdu()) + '&' + cmd
else:
cmd = 'cmd /d /c pushd ' + shortPath(os.getcwd()) + '&' + cmd
else:
b = True
pipe = subprocess.Popen(cmd, shell=b, close_fds=b, stdin=subprocess.PIPE,
stdout=subprocess.PIPE, universal_newlines=True)
pipe.stdin.close()
if asynchronous:
return pipe.stdout
output = pipe.stdout.read()
pipe.stdout.close()
return output.strip()
def shortPath(path):
''' On Windows, return the short version of "path" if possible '''
if os.name == 'nt':
from ctypes import windll, create_unicode_buffer
GetShortPathName = windll.kernel32.GetShortPathNameW
shortlen = GetShortPathName(path, 0, 0)
shortpath = create_unicode_buffer(shortlen)
if GetShortPathName(path, shortpath, shortlen):
return shortpath.value
return path
def setEnviron():
''' I do not really know why this is useful, but we might as well keep it.
NLS nuisances.
Only set these to C if already set. These must not be set unconditionally
because not all systems understand e.g. LANG=C (notably SCO).
Fixing LC_MESSAGES prevents Solaris sh from translating var values in set!
Non-C LC_CTYPE values break the ctype check.
'''
os.environ['LANG'] = os.getenv('LANG', 'C')
os.environ['LC'] = os.getenv('LC_ALL', 'C')
os.environ['LC_MESSAGE'] = os.getenv('LC_MESSAGE', 'C')
os.environ['LC_CTYPE'] = os.getenv('LC_CTYPE', 'C')
def copy_tree(src, dst,
Re: Graphics Conversion
I see where the “cache” folder is located in my user directory here : C:\Users\Didier\AppData\Roaming\LyX2.4\cache And I just spotted the configure.py file here: C:\Users\Didier\AppData\Local\Programs\LyX 2.4\Resources So ok ? - Mail original - | On Sat, Jan 27, 2024 at 12:48:40PM +0100, didiergab...@free.fr wrote: | > I'm a little lost, because I managed the discussion threads very | > poorly and I didn't always place my comments in the right | > places... | Do not worry, we will manage. | > You would like the screenshot showing the preview of the pdf file | > as seen in the Lyx window ? Here it is??? | Yes, thanks. Indeed, I see what you mean. | I have idea how to fix that, but I would need someone to confirm that | my changes work. Do you think you know how to remove cache and where | to replace configure.py if I send it? | Let's keep devel-list CC-ed. | Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Graphics Conversion
On Sat, Jan 27, 2024 at 12:48:40PM +0100, didiergab...@free.fr wrote: > I'm a little lost, because I managed the discussion threads very poorly and I > didn't always place my comments in the right places... Do not worry, we will manage. > You would like the screenshot showing the preview of the pdf file as seen in > the Lyx window ? Here it is??? Yes, thanks. Indeed, I see what you mean. I have idea how to fix that, but I would need someone to confirm that my changes work. Do you think you know how to remove cache and where to replace configure.py if I send it? Let's keep devel-list CC-ed. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Graphics Conversion
On Tue, Jan 23, 2024 at 09:22:23PM +0100, Thibaut Cuvelier wrote: > On Tue, 23 Jan 2024 at 18:35, Pavel Sanda wrote: > > > On Tue, Jan 23, 2024 at 11:58:54AM -0500, Richard Kimberly Heck wrote: > > > pdftoppm -r 72 -png -singlefile $$i > $$o > > > > This is new route in 2.4 which can be used to avoid IM problems in linux. > > We perhaps triggerred unnecessary problems on Windows. > > This could be sovled by making pdftoppm addition conditional on IM fail. > > > > And we should perhaps chech, whether accented characters are not problem > > on linux too... > > > > Could anyone on Windows post the output of Reconfigure command (you should > > be > > able to see that list in Messages pane)? > > > > Here it is, copied from the Messages pane. It's really from Reconfigure, as > the first call to configure.py happens with the installer. Thanks for the output. So pdftoppm is found correctly on windows. I tried to reproduce your problem, but I looks fine on my screen in both cases. The only difference is that IM is capable to preserve transparency of the first figure while pdftoppm can not. Apart from that it looks identical. Didier, can you send me privately your screenshot? Thibaut, can you reproduce the wrong preview with the example sent by Didier on Windows? Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Graphics Conversion
On Tue, 23 Jan 2024 at 18:35, Pavel Sanda wrote: > On Tue, Jan 23, 2024 at 11:58:54AM -0500, Richard Kimberly Heck wrote: > > pdftoppm -r 72 -png -singlefile $$i > $$o > > This is new route in 2.4 which can be used to avoid IM problems in linux. > We perhaps triggerred unnecessary problems on Windows. > This could be sovled by making pdftoppm addition conditional on IM fail. > > And we should perhaps chech, whether accented characters are not problem > on linux too... > > Could anyone on Windows post the output of Reconfigure command (you should > be > able to see that list in Messages pane)? > Here it is, copied from the Messages pane. It's really from Reconfigure, as the first call to configure.py happens with the installer. 21:13:12.436: (dialog-show aboutlyx) 21:13:17.534: Running configure... 21:13:17.664: python -tt "C:/Program Files/LyX 2.4/Resources/configure.py" --binary-dir="C:/Program Files/LyX 2.4/bin/" 21:13:17.768: +Running LyX configure with Python 3.11.2 21:13:17.770: checking for DVI to DTL converter... 21:13:17.774: +checking for "dv2dt"... yes 21:13:17.775: checking for DTL to DVI converter... 21:13:17.778: +checking for "dt2dv"... yes 21:13:17.779: checking for a Latex2e program... 21:13:17.780: +checking for "latex"... yes 21:13:17.781: checking for pLaTeX, the Japanese LaTeX... 21:13:17.781: +checking for "platex"... yes 21:13:44.327: (guessed encoding #3: ASCII = utf8)checking for a java interpreter... 21:13:44.332: +checking for "java"... yes 21:13:44.333: checking for a perl interpreter... 21:13:44.343: +checking for "perl"... yes 21:13:44.345: checking for xsltproc... 21:13:44.354: +checking for "xsltproc"... yes 21:13:45.988: checking for a Tgif viewer and editor... 21:13:46.003: +checking for "tgif"... no 21:13:46.004: checking for a FIG viewer and editor... 21:13:46.018: +checking for "xfig"... no 21:13:46.034: +checking for "jfig3-itext.jar"... no 21:13:46.049: +checking for "jfig3.jar"... no 21:13:46.051: checking for a Dia viewer and editor... 21:13:46.065: +checking for "dia"... no 21:13:46.066: checking for an OpenDocument drawing viewer and editor... 21:13:46.080: +checking for "libreoffice"... no 21:13:46.096: +checking for "lodraw"... no 21:13:46.111: +checking for "ooffice"... no 21:13:46.126: +checking for "oodraw"... no 21:13:46.142: +checking for "soffice"... no 21:13:46.144: checking for a Grace viewer and editor... 21:13:46.157: +checking for "xmgrace"... no 21:13:46.159: checking for a FEN viewer and editor... 21:13:46.176: +checking for "xboard"... no 21:13:46.178: checking for a SVG viewer and editor... 21:13:46.192: +checking for "inkscape.exe"... yes 21:13:46.193: checking for a raster image viewer... 21:13:46.209: +checking for "xv"... no 21:13:46.226: +checking for "gwenview"... no 21:13:46.242: +checking for "kview"... no 21:13:46.256: +checking for "eog"... no 21:13:46.271: +checking for "xviewer"... no 21:13:46.285: +checking for "ristretto"... no 21:13:46.300: +checking for "gpicview"... no 21:13:46.315: +checking for "lximage-qt"... no 21:13:46.329: +checking for "xdg-open"... no 21:13:46.344: +checking for "gimp-remote"... no 21:13:46.359: +checking for "gimp"... no 21:13:46.361: checking for a raster image editor... 21:13:46.374: +checking for "gimp-remote"... no 21:13:46.388: +checking for "gimp"... no 21:13:46.389: checking for a text editor... 21:13:46.404: +checking for "xemacs"... no 21:13:46.418: +checking for "gvim"... no 21:13:46.433: +checking for "kedit"... no 21:13:46.448: +checking for "kwrite"... no 21:13:46.463: +checking for "kate"... no 21:13:46.476: +checking for "nedit"... no 21:13:46.490: +checking for "gedit"... no 21:13:46.504: +checking for "geany"... no 21:13:46.519: +checking for "leafpad"... no 21:13:46.532: +checking for "mousepad"... no 21:13:46.552: +checking for "xed"... no 21:13:46.556: +checking for "notepad"... yes 21:13:46.571: +checking for "WinEdt"... no 21:13:46.587: +checking for "WinShell"... no 21:13:46.603: +checking for "PSPad"... no 21:13:46.604: checking for a lilypond editor... 21:13:46.618: +checking for "frescobaldi"... no 21:13:46.632: +checking for "xemacs"... no 21:13:46.646: +checking for "gvim"... no 21:13:46.659: +checking for "kedit"... no 21:13:46.674: +checking for "kwrite"... no 21:13:46.689: +checking for "kate"... no 21:13:46.704: +checking for "nedit"... no 21:13:46.721: +checking for "gedit"... no 21:13:46.736: +checking for "geany"... no 21:13:46.754: +checking for "leafpad"... no 21:13:46.771: +checking for "mousepad"... no 21:13:46.786: +checking for "xed"... no 21:13:46.792: +checking for "notepad"... yes 21:13:46.809: +checking for "WinEdt"... no 21:13:46.824: +checking for "WinShell"... no 21:13:46.838: +checking for "PSPad"... no 21:13:46.839: checking for gnumeric spreadsheet software... 21:13:46.854: +checking for "gnumeric"... no 21:13:46.856: checking for an HTML previewer... 21:13:46.869: +checking for
Re: Graphics Conversion
On 1/23/24 12:33, Pavel Sanda wrote: On Tue, Jan 23, 2024 at 11:58:54AM -0500, Richard Kimberly Heck wrote: pdftoppm -r 72 -png -singlefile $$i > $$o This is new route in 2.4 which can be used to avoid IM problems in linux. We perhaps triggerred unnecessary problems on Windows. This could be sovled by making pdftoppm addition conditional on IM fail. The conversion on 2.3.7 is to EPS (according ot the posted logs), rather than PNG, which is why it works better. I'm not sure why we're choosing PNG instead on 2.4. On my system here, it chooses EPS. Didier, do you have a PDF to EPS converter listed in your 2.4 install? And we should perhaps chech, whether accented characters are not problem on linux too... It shouldn't be. This is the toFilesystemEncoding vs toSafeFilesystemEncoding issue again, where the former is known not to work with non-ASCII characters on Windows, whereas it does work (at least according to the comments) on *nix and derivatives. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Graphics Conversion
On Tue, Jan 23, 2024 at 11:58:54AM -0500, Richard Kimberly Heck wrote: > pdftoppm -r 72 -png -singlefile $$i > $$o This is new route in 2.4 which can be used to avoid IM problems in linux. We perhaps triggerred unnecessary problems on Windows. This could be sovled by making pdftoppm addition conditional on IM fail. And we should perhaps chech, whether accented characters are not problem on linux too... Could anyone on Windows post the output of Reconfigure command (you should be able to see that list in Messages pane)? Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Graphics Conversion
Here it is. Here is the command I can see under Tools> Preferences> File Handling> Converters, at the PDF to PNG converter: « pdftoppm -r 72 -png -singlefile $$i > $$o » as you said... I’ll try to increase the dpi ps : On these computer svg from inkscape preview is ok so good point. - Mail original - | On 1/23/24 04:06, didiergab...@free.fr wrote: | | I am currently in front of my Windows 10 PC at my workplace with | | which I am experiencing exactly the same symptoms. | | | I followed your instructions, and you will find the requested file | | attached. | | | I will do the same thing again this evening at home, with my | | personal | | computer. | | This is plenty good enough. The difference is indeed what converter | is being called. In your case, it looks to be low resolution. I'm | puzzled why this is different on 2.3.7. You could try running the | same test with it. That would tell us. | You could also look under Tools> Preferences> File Handling> | Converters, at the PDF to PNG converter. The command listed there | will be: | pdftoppm -r 72 -png -singlefile $$i > $$o | The -r 72 is controlling resolution. You could try increasing that. | | ps: The Schemacinematic.pdf document was created with inkscape... | | Which I sometimes export to pdf because I cannot activate, in the | | Lyx window, the preview of inkscape documents in the native svg | | format. However, adding an inkscape in float fig document works | | very | | well in pdfLaTex export, so I often do without the preview. Should | | the preview of inkscape svg documents be operational or is it a | | configuration problem / choice of settings that I made incorrectly? | | It should work. Here, the SVG to PNG converter is inkscape itself. | Maybe LyX is not finding it. Again, check the list of converters, | and see if you have anything for SVG. | Riki 18:13:11.027: (dialog-toggle progress) 18:13:35.144: Ouverture du document G:\CPGE\PTSI\DS\DS-2023-2024\DS3\MWE-PDF preview.23.lyx... 18:13:35.225: Document G:\CPGE\PTSI\DS\DS-2023-2024\DS3\MWE-PDF preview.23.lyx ouvert. 18:13:35.225: (file-open: Ctrl+O)Format.cpp (389): filetools(getFormatFromContents) File type not recognised before EOF! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (389): filetools(getFormatFromContents) File type not recognised before EOF! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (391): Recognised Fileformat: latex Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (389): filetools(getFormatFromContents) File type not recognised before EOF! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (389): filetools(getFormatFromContents) File type not recognised before EOF! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (391): Recognised Fileformat: latex Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (391): Recognised Fileformat: latex Format.cpp (507): will guess format from file extension: lyx -> lyx Format.cpp (389): filetools(getFormatFromContents) File type not recognised before EOF! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (389): filetools(getFormatFromContents) File type not recognised before EOF! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (389): filetools(getFormatFromContents) File type not recognised before EOF! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (396): filetools(getFormatFromContents) Couldn't find a known format! Format.cpp (389):
Re: Graphics Conversion
On 1/23/24 04:06, didiergab...@free.fr wrote: I am currently in front of my Windows 10 PC at my workplace with which I am experiencing exactly the same symptoms. I followed your instructions, and you will find the requested file attached. I will do the same thing again this evening at home, with my personal computer. This is plenty good enough. The difference is indeed what converter is being called. In your case, it looks to be low resolution. I'm puzzled why this is different on 2.3.7. You could try running the same test with it. That would tell us. You could also look under Tools> Preferences> File Handling> Converters, at the PDF to PNG converter. The command listed there will be: pdftoppm -r 72 -png -singlefile $$i > $$o The -r 72 is controlling resolution. You could try increasing that. ps: The Schemacinematic.pdf document was created with inkscape... Which I sometimes export to pdf because I cannot activate, in the Lyx window, the preview of inkscape documents in the native svg format. However, adding an inkscape in float fig document works very well in pdfLaTex export, so I often do without the preview. Should the preview of inkscape svg documents be operational or is it a configuration problem / choice of settings that I made incorrectly? It should work. Here, the SVG to PNG converter is inkscape itself. Maybe LyX is not finding it. Again, check the list of converters, and see if you have anything for SVG. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Graphics conversion export LaTeX: crippled LaTeX file
On Friday 01 March 2002 12:27 pm, R. Lahaye wrote:
Hi,
A former thread at this list has guided me through how
to use Grace files (2D-graphics package) as input files
for the Graphics/figure inset. Works great in LyX!!!
However, when I export my LyX file as LaTeX, the Grace
files are exported as figure files. When I then run latex
on this newly exported LaTeX file, it complains about the
unknown Grace filetype:
[...]
! LaTeX Error: Cannot determine size of graphic in
/home/lahaye/figures/newfig.agr (no BoundingBox).
See the LaTeX manual or LaTeX Companion for explanation.
Type H return for immediate help.
...
l.253 ...65]{/home/lahaye/figures/newfig.agr}
?
I suppose this is a general problem with the conversion mechanism
and exporting latex, isn't it?
Is there a general solution to this problem?
LaTeX can only handle (e)ps files, can't it?
An option could be to replace any file extension by eps and leave
it up the user to generate these eps files manually.
Or not leave that up to the user, but generate automagically also
the accompanying eps files using the conversion descriptions.
As it is now, the latex file is unusable.
Maybe. Maybe the fault is with you.
You need to define also a converter from agr to eps. Have you done so?
Run -dbg graphics to see what lyx is doing.
Angus
Re: Graphics conversion export LaTeX: crippled LaTeX file
Angus Leeming wrote: On Friday 01 March 2002 12:27 pm, R Lahaye wrote: I suppose this is a general problem with the conversion mechanism and exporting latex, isn't it? As it is now, the latex file is unusable Maybe Maybe the fault is with you You need to define also a converter from agr to eps Have you done so? Run -dbg graphics to see what lyx is doing Now you are confusing me terribly! The one and only thing I actually have defined for my agr files, IS a converter from agr to eps That's all I've got With that -dbg option I get, when I export to LaTeX: [] filetools(getExtFromContents) Couldn't find a known Type! will use ext or a user defined format don't unzip file or export latex/home/lahaye/figures/newfigagr [] Any idea what's going wrong here? It appears that the 'filetools'-thing works for LyX itself, but not for exportingor something like that Regards, Rob
Re: Graphics conversion export LaTeX: crippled LaTeX file
On Fri, 1 Mar 2002, R Lahaye wrote: With that -dbg option I get, when I export to LaTeX: [] filetools(getExtFromContents) Couldn't find a known Type! will use ext or a user defined format don't unzip file or export latex/home/lahaye/figures/newfigagr [] Any idea what's going wrong here? It appears that the 'filetools'-thing works for LyX itself, but not for exportingor something like that filetools returns a fileformat, nothing else and it works independet from what to do with this file Herbert
Re: Graphics conversion export LaTeX: crippled LaTeX file
On Friday 01 March 2002 12:48 pm, R. Lahaye wrote: Angus Leeming wrote: On Friday 01 March 2002 12:27 pm, R. Lahaye wrote: I suppose this is a general problem with the conversion mechanism and exporting latex, isn't it? As it is now, the latex file is unusable. Maybe. Maybe the fault is with you. You need to define also a converter from agr to eps. Have you done so? Run -dbg graphics to see what lyx is doing. Now you are confusing me terribly! The one and only thing I actually have defined for my agr files, IS a converter from agr to eps. That's all I've got. And you have a format definition too, right? In my lyxrc.defaults I have \Format graceagrGRACE \converter agr eps xmgrace -hardcopy -hdevice EPS $$i If you don't, then you should cvs update autogen.sh configure You shouldn't need to make anything.
Re: Graphics conversion export LaTeX: crippled LaTeX file
On Fri, 1 Mar 2002, Angus Leeming wrote: In my lyxrcdefaults I have \Format graceagr GRACE \converter agr eps xmgrace -hardcopy -hdevice EPS $$i If you don't, then you should cvs update autogensh configure You shouldn't need to make anything the last patch does this by default But I remember that we also need a agr-gif-xpm to speed up the conversion xmgrace has no -xpm or am I wrong??? Herbert
Re: Graphics conversion & export LaTeX: crippled LaTeX file
On Friday 01 March 2002 12:27 pm, R. Lahaye wrote:
> Hi,
>
> A former thread at this list has guided me through how
> to use Grace files (2D-graphics package) as input files
> for the Graphics/figure inset. Works great in LyX!!!
>
> However, when I export my LyX file as LaTeX, the Grace
> files are exported as figure files. When I then run latex
> on this newly exported LaTeX file, it complains about the
> unknown Grace filetype:
>
> [...]
> ! LaTeX Error: Cannot determine size of graphic in
/home/lahaye/figures/newfig.agr (no BoundingBox).
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type H for immediate help.
> ...
>
> l.253 ...65]{/home/lahaye/figures/newfig.agr}
>
> ?
>
> I suppose this is a general problem with the conversion mechanism
> and exporting latex, isn't it?
>
> Is there a general solution to this problem?
> LaTeX can only handle (e)ps files, can't it?
> An option could be to replace any file extension by "eps" and leave
> it up the user to generate these eps files manually.
> Or not leave that up to the user, but generate automagically also
> the accompanying eps files using the conversion descriptions.
>
> As it is now, the latex file is unusable.
Maybe. Maybe the fault is with you.
You need to define also a converter from agr to eps. Have you done so?
Run -dbg graphics to see what lyx is doing.
Angus
Re: Graphics conversion & export LaTeX: crippled LaTeX file
Angus Leeming wrote: > > On Friday 01 March 2002 12:27 pm, R. Lahaye wrote: > > > > I suppose this is a general problem with the conversion mechanism > > and exporting latex, isn't it? > > > > As it is now, the latex file is unusable. > > Maybe. Maybe the fault is with you. > > You need to define also a converter from agr to eps. Have you done so? > > Run -dbg graphics to see what lyx is doing. Now you are confusing me terribly! The one and only thing I actually have defined for my agr files, IS a converter from agr to eps. That's all I've got. With that -dbg option I get, when I export to LaTeX: [...] filetools(getExtFromContents) Couldn't find a known Type! will use ext or a "user" defined format don't unzip file or export latex/home/lahaye/figures/newfig.agr [...] Any idea what's going wrong here? It appears that the 'filetools'-thing works for LyX itself, but not for exporting.or something like that. Regards, Rob.
Re: Graphics conversion & export LaTeX: crippled LaTeX file
On Fri, 1 Mar 2002, R. Lahaye wrote: > With that -dbg option I get, when I export to LaTeX: > > [...] > filetools(getExtFromContents) > Couldn't find a known Type! > will use ext or a "user" defined format > don't unzip file or export latex/home/lahaye/figures/newfig.agr > [...] > > Any idea what's going wrong here? > It appears that the 'filetools'-thing works for LyX itself, but > not for exporting.or something like that. filetools returns a fileformat, nothing else. and it works independet from what to do with this file. Herbert
Re: Graphics conversion & export LaTeX: crippled LaTeX file
On Friday 01 March 2002 12:48 pm, R. Lahaye wrote: > Angus Leeming wrote: > > > > On Friday 01 March 2002 12:27 pm, R. Lahaye wrote: > > > > > > I suppose this is a general problem with the conversion mechanism > > > and exporting latex, isn't it? > > > > > > As it is now, the latex file is unusable. > > > > Maybe. Maybe the fault is with you. > > > > You need to define also a converter from agr to eps. Have you done so? > > > > Run -dbg graphics to see what lyx is doing. > > Now you are confusing me terribly! > The one and only thing I actually have defined for my agr files, > IS a converter from agr to eps. That's all I've got. And you have a format definition too, right? In my lyxrc.defaults I have \Format graceagrGRACE "" \converter agr eps "xmgrace -hardcopy -hdevice EPS $$i" "" If you don't, then you should cvs update autogen.sh configure You shouldn't need to "make" anything.
Re: Graphics conversion & export LaTeX: crippled LaTeX file
On Fri, 1 Mar 2002, Angus Leeming wrote: > In my lyxrc.defaults I have > > \Format graceagr GRACE "" > \converter agr eps "xmgrace -hardcopy -hdevice EPS $$i" "" > > If you don't, then you should > cvs update > autogen.sh > configure > You shouldn't need to "make" anything. the last patch does this by default. But I remember that we also need a agr->gif->xpm to speed up the conversion. xmgrace has no ->xpm or am I wrong??? Herbert
