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, preserve_
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, preserve_sym
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 "fi
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): filetools(
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 display on lyx-screen depends on cache
On Thu, Jun 14, 2018 at 06:37:17PM +, Kornel Benko wrote: > Am Donnerstag, 14. Juni 2018 13:51:33 CEST schrieb Scott Kostyshak > : > > On Thu, Jun 14, 2018 at 09:26:39AM +, Kornel Benko wrote: > > > Am Donnerstag, 14. Juni 2018 03:01:51 CEST schrieb Scott Kostyshak > > > : > > > > On Thu, May 10, 2018 at 11:32:37AM +, Kornel Benko wrote: > > > > > The graphics display looks wrong if cache is enabled. > > > > > Attached versions of oxygen fonts.svgz. > > > > > (Master and 2.3.x show the same behavior) > > > > > (Some cropping error on the upper side?) > > > > > > > > What are the steps to reproduce? > > > > > > > > Scott > > > > > > 1.) select oxygen in Tools->Preferences...->Look & Feel->User > > > Interface->Icon set: > > > 2.) select Enabled in Tools->Preferences...->File > > > Handling->Converters->Converter File Cache > > > 3.) select ON in Tools->Preferences...->Look & Feel->Display->Instant > > > Preview: > > > 4.) restart lyx (THIS IS IMPORTANT) > > > 5.) open doc/attic/eu_UserGuide.lyx > > > 6.) For instance go to section 5.1.4, first graphic > > > > > > for reference > > > 7.) disable file cache > > > 8.) restart lyx > > > 9.) go to section 5.1.4, first graphic, looks much better > > > > Thank you for those clear instructions! > > > > My screenshots after6.png (taken after step 6), and after9.png (taken > > after step 9), look the same to me (except for the bluetooth icon since > > my headphones ran out of batter in-between). Did I make a mistake in > > following the instructions? I might be seeing a different issue than > > you: For me, the first graphic is huge in both cases. > > > > Scott > > Which qt-version? > My was 5.6.1. Mine is 5.6.2 (might be 5.6.2dev, not sure). > Don't see the effect with 5.11. and identical userdir. I think, we may ignore > this subject. > Still amazing. Ah good to know. Yeah, I guess let's forget about it for now. Scott signature.asc Description: PGP signature
Re: Graphics display on lyx-screen depends on cache
Am Donnerstag, 14. Juni 2018 13:51:33 CEST schrieb Scott Kostyshak : > On Thu, Jun 14, 2018 at 09:26:39AM +, Kornel Benko wrote: > > Am Donnerstag, 14. Juni 2018 03:01:51 CEST schrieb Scott Kostyshak > > : > > > On Thu, May 10, 2018 at 11:32:37AM +, Kornel Benko wrote: > > > > The graphics display looks wrong if cache is enabled. > > > > Attached versions of oxygen fonts.svgz. > > > > (Master and 2.3.x show the same behavior) > > > > (Some cropping error on the upper side?) > > > > > > What are the steps to reproduce? > > > > > > Scott > > > > 1.) select oxygen in Tools->Preferences...->Look & Feel->User > > Interface->Icon set: > > 2.) select Enabled in Tools->Preferences...->File > > Handling->Converters->Converter File Cache > > 3.) select ON in Tools->Preferences...->Look & Feel->Display->Instant > > Preview: > > 4.) restart lyx (THIS IS IMPORTANT) > > 5.) open doc/attic/eu_UserGuide.lyx > > 6.) For instance go to section 5.1.4, first graphic > > > > for reference > > 7.) disable file cache > > 8.) restart lyx > > 9.) go to section 5.1.4, first graphic, looks much better > > Thank you for those clear instructions! > > My screenshots after6.png (taken after step 6), and after9.png (taken > after step 9), look the same to me (except for the bluetooth icon since > my headphones ran out of batter in-between). Did I make a mistake in > following the instructions? I might be seeing a different issue than > you: For me, the first graphic is huge in both cases. > > Scott Which qt-version? My was 5.6.1. Don't see the effect with 5.11. and identical userdir. I think, we may ignore this subject. Still amazing. Kornel signature.asc Description: This is a digitally signed message part.
Re: Graphics display on lyx-screen depends on cache
Am Donnerstag, 14. Juni 2018 03:01:51 CEST schrieb Scott Kostyshak : > On Thu, May 10, 2018 at 11:32:37AM +, Kornel Benko wrote: > > The graphics display looks wrong if cache is enabled. > > Attached versions of oxygen fonts.svgz. > > (Master and 2.3.x show the same behavior) > > (Some cropping error on the upper side?) > > What are the steps to reproduce? > > Scott 1.) select oxygen in Tools->Preferences...->Look & Feel->User Interface->Icon set: 2.) select Enabled in Tools->Preferences...->File Handling->Converters->Converter File Cache 3.) select ON in Tools->Preferences...->Look & Feel->Display->Instant Preview: 4.) restart lyx (THIS IS IMPORTANT) 5.) open doc/attic/eu_UserGuide.lyx 6.) For instance go to section 5.1.4, first graphic for reference 7.) disable file cache 8.) restart lyx 9.) go to section 5.1.4, first graphic, looks much better Kornel signature.asc Description: This is a digitally signed message part.
Re: Graphics display on lyx-screen depends on cache
On Thu, May 10, 2018 at 11:32:37AM +, Kornel Benko wrote: > The graphics display looks wrong if cache is enabled. > Attached versions of oxygen fonts.svgz. > (Master and 2.3.x show the same behavior) > (Some cropping error on the upper side?) What are the steps to reproduce? Scott signature.asc Description: PGP signature
Re: Graphics preview broken (was: [LyX/2.3.x] Update scripts to support simultaneously python 2 and 3)
Richard Kimberly Heck wrote: > On 06/07/2018 02:56 AM, Pavel Sanda wrote: > > Scott Kostyshak wrote: > >> This is the same issue as discussed here: > >> > >> https://www.mail-archive.com/search?l=mid&q=1603612.ofyPDf553K%40amd64 > > Indeed, when the patch in master is applied to branch the problem is gone. > > I guess we'd better apply that one then, yes? Anyone can do it... Ok, I cherry-picked Enrico's commit. Pavel
Re: Graphics preview broken (was: [LyX/2.3.x] Update scripts to support simultaneously python 2 and 3)
On 06/07/2018 02:56 AM, Pavel Sanda wrote: > Scott Kostyshak wrote: >> This is the same issue as discussed here: >> >> https://www.mail-archive.com/search?l=mid&q=1603612.ofyPDf553K%40amd64 > Indeed, when the patch in master is applied to branch the problem is gone. I guess we'd better apply that one then, yes? Anyone can do it... Riki
Re: Graphics preview broken (was: [LyX/2.3.x] Update scripts to support simultaneously python 2 and 3)
Scott Kostyshak wrote: > This is the same issue as discussed here: > > https://www.mail-archive.com/search?l=mid&q=1603612.ofyPDf553K%40amd64 Indeed, when the patch in master is applied to branch the problem is gone. Pavel
Re: Graphics preview broken (was: [LyX/2.3.x] Update scripts to support simultaneously python 2 and 3)
On Wed, Jun 06, 2018 at 09:49:09PM +, Pavel Sanda wrote: > Taking back. To correctly reproduce the problem, one needs to empty the > image cache. Bisect then leads to: > > commit a1579c583acb22a7f5dae80a9bfe7707774f49a4 This is the same issue as discussed here: https://www.mail-archive.com/search?l=mid&q=1603612.ofyPDf553K%40amd64 I wish I had seen your thread earlier to try to save you from the bisect. Scott signature.asc Description: PGP signature
Re: Graphics No Longer Converted in Background
On 02/03/2011 11:27 AM, Richard Heck wrote: In attempting to look at #7163, I have found that graphics are no longer being converted in the background, after the Buffer loads. The reason seems to be r29473, which is triggering a metrics calculation for the whole Buffer that is then forcing each graphic to be loaded. Never mind. This was only because I put them all in one paragraph in my test file. rh
Re: Graphics file not found
Yes, the graphics reload command solves the problem! Dave Raymond Vincent van Ravesteijn writes: > David Raymond schreef: > > If one imports a graphics file into a lyx document, close the > > document, and then delete the graphics file, the next time that the > > document is opened, lyx reports that the graphics file cannot be > > found. Fair enough. However, if the graphics file is recreated while > > lyx still has the document open, lyx still insists that the graphics > > file doesn't exist, even if the graphics is deleted and re-imported > > into the document. Only by exiting lyx and restarting it is the newly > > re-created graphics file found again. > > > > This seems like a bug to me. > > > > Dave Raymond > > > > What do you mean with re-imported ? Did you really removed the Graphics > at all, or did you only choose the same filename again ? Maybe we shoul > refresh in this case, that may be a bug. > > Did you try the new "Graphics Reload" feature ? Right-click on the > graphics, and choose Reload (1.6.5 only). > > Vincent
Re: Graphics file not found
I actually deleted the image and restarted lyx. I then recreated the image and lyx couldn't find it even if I deleted the graphic from the document and added it to the document again. Let me try the graphics reload feature -- I didn't notice that. Dave Raymond Vincent van Ravesteijn writes: > David Raymond schreef: > > If one imports a graphics file into a lyx document, close the > > document, and then delete the graphics file, the next time that the > > document is opened, lyx reports that the graphics file cannot be > > found. Fair enough. However, if the graphics file is recreated while > > lyx still has the document open, lyx still insists that the graphics > > file doesn't exist, even if the graphics is deleted and re-imported > > into the document. Only by exiting lyx and restarting it is the newly > > re-created graphics file found again. > > > > This seems like a bug to me. > > > > Dave Raymond > > > > What do you mean with re-imported ? Did you really removed the Graphics > at all, or did you only choose the same filename again ? Maybe we shoul > refresh in this case, that may be a bug. > > Did you try the new "Graphics Reload" feature ? Right-click on the > graphics, and choose Reload (1.6.5 only). > > Vincent
Re: Graphics file not found
David Raymond schreef: If one imports a graphics file into a lyx document, close the document, and then delete the graphics file, the next time that the document is opened, lyx reports that the graphics file cannot be found. Fair enough. However, if the graphics file is recreated while lyx still has the document open, lyx still insists that the graphics file doesn't exist, even if the graphics is deleted and re-imported into the document. Only by exiting lyx and restarting it is the newly re-created graphics file found again. This seems like a bug to me. Dave Raymond What do you mean with re-imported ? Did you really removed the Graphics at all, or did you only choose the same filename again ? Maybe we shoul refresh in this case, that may be a bug. Did you try the new "Graphics Reload" feature ? Right-click on the graphics, and choose Reload (1.6.5 only). Vincent
Re: graphics
2009/3/3 Bob Wonderly : > I have a LyX math book in the works. It is in landscape format so I can show > wide page sized graphics -- PDF files (generated by gnuplot and converted to > PDF by AquaTerm). > > The output book file (using pdflatex) shows only part of the graphic. > Nothing I have tried has convinced LyX to show the whole plot/graphic. > > Could someone help me -- off list perhaps -- get LyX to display the entire > graphic? > > I would like to send the PDF file but it is 400KB and I did not want to do > that to the list. > > Actually, of course, I have a whole bunch of such PDFs to display and can't > even get the first one working right. > > Thanks > > Bob Wonderly We, LyX users here on the list, do not prefer off-list solutions* - this is library of solutions for further generations of users. Did you use options in image properties dialog which allows to set width or height of the picture in percentage of with of text column or page? Try that, if not. It works in most cases. If you still have problems, please provide more details about your document, such as style (document class) you use, packages loaded, whether your pictures are floating or not... etc. * - sometimes with deep technical problems some developers drive finding solutions off-lists, sharing results later. -- Manveru jabber: manv...@manveru.pl gg: 1624001 http://www.manveru.pl
Re: Graphics handling when file not found
> which probably does what you want. It may make more sense however to > have a version that requires a reference directory as argument. just a question .. does this somehow interfere with the new embeding stuff in 1.6? pavel
Re: Graphics handling when file not found
Vasek Smidl <[EMAIL PROTECTED]> writes: > Yeah, I think it is the latter. > In changeset/3881 the detection is: > (IsFileReadable(MakeAbsPath(params().filename, buf->filePath())) > > while now it is: >isFileReadable(params().filename); > > So it is checked by a different function, (lowercase is* in place of > uppercase Is*). So I guess that some detection (perhaps related to > missing "MakeAbsPath") is not being done. The change of case is just a general renaming that we did at some point in time. I do not think that the change you outline can be responsible for problems with files that are found through latex. > Before I go further in investigating this I would like to know if > there is a general agreement whether files on latex paths > (kpsewhich) should or should not be visible to LyX. Personally, I think we should do that. You should have a look at /** * Search a TeX file in all locations the latex compiler would search it, * with the help of kpsewhich. * The current working directory must be set correctly, so that relative * names work. * \param fil The filename to search * \param format The file format as used by kpsewhich, e.g. "bib", "bst" etc. */ FileName const findtexfile(std::string const & fil, std::string const & format); which probably does what you want. It may make more sense however to have a version that requires a reference directory as argument. JMarc
Re: Graphics handling when file not found
Pavel Sanda <[EMAIL PROTECTED]> writes: > > > I came across the situation when some of my older lyx files could no longer > > compile under new versions of LyX. Well, the file is about 5 years old, and I haven't tried to compile it since, so the problem may actually be there quite a long time... > > looking on the commit history this line has been introduced by Herbert > http://www.lyx.org/trac/changeset/3881 > and the only interesting change was made by > http://www.lyx.org/trac/changeset/5238 > both 6 years back, so i'm not sure what you mean by new version :) > > but may be lyx2lyx do some nasty thing or detection of file_exists changed. Yeah, I think it is the latter. In changeset/3881 the detection is: (IsFileReadable(MakeAbsPath(params().filename, buf->filePath())) while now it is: isFileReadable(params().filename); So it is checked by a different function, (lowercase is* in place of uppercase Is*). So I guess that some detection (perhaps related to missing "MakeAbsPath") is not being done. Before I go further in investigating this I would like to know if there is a general agreement whether files on latex paths (kpsewhich) should or should not be visible to LyX. Vasek
Re: Graphics handling when file not found
> I came across the situation when some of my older lyx files could no longer > compile under new versions of LyX. looking on the commit history this line has been introduced by Herbert http://www.lyx.org/trac/changeset/3881 and the only interesting change was made by http://www.lyx.org/trac/changeset/5238 both 6 years back, so i'm not sure what you mean by new version :) but may be lyx2lyx do some nasty thing or detection of file_exists changed. pavel
Re: graphics dialog
Andre Poenitz wrote: Probably. After the merging there's quite some cruft of the thin-wrapper-around-misbehaving-thin-wrappers style left. Bugfixing might be as simple as removing stuff... i put it in: http://www.lyx.org/trac/changeset/20172
Re: graphics dialog
On Sun, Sep 09, 2007 at 01:50:32PM +0200, Edwin Leuven wrote: > Edwin Leuven wrote: > >the attached makes it usable again... > > and i guess these can all go Probably. After the merging there's quite some cruft of the thin-wrapper-around-misbehaving-thin-wrappers style left. Bugfixing might be as simple as removing stuff... Andre'
Re: graphics dialog
On Sun, Sep 09, 2007 at 01:06:35PM +0200, Edwin Leuven wrote: > the attached makes it usable again... Thanks. Andre'
Re: graphics dialog
Edwin Leuven wrote:
the attached makes it usable again...
and i guess these can all go
Index: src/frontends/qt4/GuiExternal.cpp
===
--- src/frontends/qt4/GuiExternal.cpp (revision 20164)
+++ src/frontends/qt4/GuiExternal.cpp (working copy)
@@ -190,12 +190,6 @@
}
-void GuiExternalDialog::showView()
-{
- QDialog::show();
-}
-
-
bool GuiExternalDialog::activateAspectratio() const
{
if (widthUnitCO->currentIndex() == 0)
Index: src/frontends/qt4/GuiExternal.h
===
--- src/frontends/qt4/GuiExternal.h (revision 20164)
+++ src/frontends/qt4/GuiExternal.h (working copy)
@@ -42,7 +42,6 @@
private:
public:
- void showView();
void closeEvent(QCloseEvent * e);
//
bool activateAspectratio() const;
Index: src/frontends/qt4/GuiGraphics.cpp
===
--- src/frontends/qt4/GuiGraphics.cpp (revision 20164)
+++ src/frontends/qt4/GuiGraphics.cpp (working copy)
@@ -217,12 +217,6 @@
}
-void GuiGraphicsDialog::showView()
-{
- QDialog::show();
-}
-
-
void GuiGraphicsDialog::change_adaptor()
{
changed();
Index: src/frontends/qt4/GuiGraphics.h
===
--- src/frontends/qt4/GuiGraphics.h (revision 20164)
+++ src/frontends/qt4/GuiGraphics.h (working copy)
@@ -30,7 +30,6 @@
public:
GuiGraphicsDialog(LyXView & lv);
void setAutoText();
- void showView();
private Q_SLOTS:
void change_adaptor();
void change_bb();
Index: src/frontends/qt4/GuiInclude.cpp
===
--- src/frontends/qt4/GuiInclude.cpp (revision 20164)
+++ src/frontends/qt4/GuiInclude.cpp (working copy)
@@ -84,12 +84,6 @@
}
-void GuiIncludeDialog::showView()
-{
- QDialog::show();
-}
-
-
void GuiIncludeDialog::change_adaptor()
{
changed();
Index: src/frontends/qt4/GuiInclude.h
===
--- src/frontends/qt4/GuiInclude.h (revision 20164)
+++ src/frontends/qt4/GuiInclude.h (working copy)
@@ -43,8 +43,6 @@
ControlInclude & controller() const;
///
void updateLists();
- ///
- void showView();
/// validate listings parameters and return an error message, if any
docstring validate_listings_params();
Index: src/frontends/qt4/GuiNomencl.cpp
===
--- src/frontends/qt4/GuiNomencl.cpp (revision 20164)
+++ src/frontends/qt4/GuiNomencl.cpp (working copy)
@@ -59,12 +59,6 @@
}
-void GuiNomenclDialog::showView()
-{
- QDialog::show();
-}
-
-
void GuiNomenclDialog::change_adaptor()
{
changed();
Index: src/frontends/qt4/GuiNomencl.h
===
--- src/frontends/qt4/GuiNomencl.h (revision 20164)
+++ src/frontends/qt4/GuiNomencl.h (working copy)
@@ -34,8 +34,6 @@
private:
///
- void showView();
- ///
void closeEvent(QCloseEvent * e);
/// parent controller
ControlCommand & controller() const;
Index: src/frontends/qt4/GuiRef.cpp
===
--- src/frontends/qt4/GuiRef.cpp (revision 20164)
+++ src/frontends/qt4/GuiRef.cpp (working copy)
@@ -94,12 +94,6 @@
}
-void GuiRefDialog::showView()
-{
- QDialog::show();
-}
-
-
void GuiRefDialog::changed_adaptor()
{
changed();
Index: src/frontends/qt4/GuiRef.h
===
--- src/frontends/qt4/GuiRef.h (revision 20164)
+++ src/frontends/qt4/GuiRef.h (working copy)
@@ -42,8 +42,6 @@
private:
///
- void showView();
- ///
void closeEvent(QCloseEvent * e);
/// parent controller
ControlRef & controller() const;
Re: graphics converter broken
Michael Gerz schrieb: Something for the python gurus: File "C:/Dokumente und Einstellungen/user/Lokale Einstellungen/Temp/lyx_tmpdir4040a03468/lyxconvert0.py", line 11 SyntaxError: Non-ASCII character '\xc3' in file C:/Dokumente und Einstellungen/user/Lokale Einstellungen/Temp/lyx_tmpdir4040a03468/lyxconvert0.py on line 11, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details I think the underlying problem is that lyxconvert0.py tries to convert a graphics whose path name contains a German Umlaut. The original bug has gone but now I am facing another one: Traceback (most recent call last): File "C:/Dokumente und Einstellungen/itsme/Lokale Einstellungen/Temp/lyx_tmpdir1584a02224/lyxconvert0.py", line 14, in ... IOError: [Errno 2] No such file or directory: 'C:/dokumente und einstellungen/itsme/Ver\xc3\xb6ffentlichungen/figures/myfigure.pdf' Again, there is a problem with a German Umlaut (ö = \xc3\xb6) Michael
Re: graphics converter broken
On Thursday 28 December 2006 18:20, Michael Gerz wrote: > Something for the python gurus: > > File "C:/Dokumente und Einstellungen/user/Lokale > Einstellungen/Temp/lyx_tmpdir4040a03468/lyxconvert0.py", line 11 > SyntaxError: Non-ASCII character '\xc3' in file C:/Dokumente und > Einstellungen/user/Lokale > Einstellungen/Temp/lyx_tmpdir4040a03468/lyxconvert0.py on line 11, but > no encoding declared; see http://www.python.org/peps/pep-0263.html for > details > > I think the underlying problem is that lyxconvert0.py tries to convert a > graphics whose path name contains a German Umlaut. Yes. It is only a warning here. I added the missing encoding declaration. Georg
Re: Graphics won't convert
On Aug 6, 2006, at 10:00 PM, TJ wrote: Ive been searching around the web for an answer to this problem and can find nothing. I am running a Mac with the latest version of OS X and I have followed the installation page that I found on one of the Lyx.org linked sites. My question is when I put a jpg or any other graphic in the document and then try to view it in any of the output views I get the error "No Information for converting jpg format files to eps. Define a converter in the preferences." I understand that I need a converter to do this but how do I add one? Which one do I use? Another item of frustration for me is that when I try and run the view=>DVI command it does nothing. Any help would be great. It sounds like you don't have ImageMagick installed. You can get it using i-Installer or fink, e.g. Once you've installed it, select Tools > Reconfigure from within LyX, quit, and restart. Then it should work. Bennett
Re: Graphics files with spaces again!
Am Samstag, 9. Juli 2005 00:33 schrieb João Luis Meloni Assirati: > There is a problem with the patch: Thanks for spotting this. It is fixed now. Parts from the next patch slipped in ;-) Georg
Re: Graphics files with spaces again!
Georg,
Em Sex 08 Jul 2005 12:11, Georg Baum escreveu:
> Angus Leeming wrote:
> > Ok, the problem is that ChangeExtension calls os::internal_path
> > internally, so the \ characters here are converted to / ones:
> > path = ChangeExtension("\\string\"" + base + "\\string\"", ext);
>
> Attached is the equivalent patch for 1.4. Note that I also changed the
> external inset where it made sense. This quoting business does not play
> well with the external inset, since it may require to add the extension,
> but IMO we should ignore that.
>
> BTW, I was not very successful with my pdftex bug report:
>
> http://sarovar.org/tracker/?func=detail&atid=493&aid=377&group_id=106
>
> Does somebody have the time to create a \pdfximage external template?
>
>
> I will apply the patch shortly.
There is a problem with the patch:
g++ -DHAVE_CONFIG_H -I. -I../../../src/insets -I../../src
-I../../../src/insets/.. -I../../../boost -W -Wall -I/usr/X11R6/include
-fno-exceptions -g -O2 -fno-exceptions
-c ../../../src/insets/ExternalSupport.C -o ExternalSupport.o
../../../src/insets/ExternalSupport.C: In function `const std::string
lyx::externalsubst_path(const std::string&, const
std::string&,
const std::string&, bool, bool)':
../../../src/insets/ExternalSupport.C:75: error: `use_lyxdot' undeclared
(first
use this function)
../../../src/insets/ExternalSupport.C:75: error: (Each undeclared identifier
is
reported only once for each function it appears in.)
make[3]: ** [ExternalSupport.lo] Erro 1
Also, it misses a semicolon
-std::string const latex_path(std::string const & path);
+std::string const latex_path(std::string const & path,
+ bool exclude_extension = false)<--- Here
Regards,
João.
Re: Graphics files with spaces again!
Georg Baum wrote:
>> Ok, the problem is that ChangeExtension calls os::internal_path
>> internally, so the \ characters here are converted to / ones:
>> path = ChangeExtension("\\string\"" + base + "\\string\"",
>> ext);
>
> Attached is the equivalent patch for 1.4. Note that I also changed
> the external inset where it made sense. This quoting business does
> not play well with the external inset, since it may require to add
> the extension, but IMO we should ignore that.
Agreed. Almost nobody uses the inset yet anyway.
> BTW, I was not very successful with my pdftex bug report:
>http://sarovar.org/tracker/?func=detail&atid=493&aid=377&group_id=106
Executive summary: the current system is completely broken, but we
won't fix it because we haven't devised the ideal solution ;-)
> Does somebody have the time to create a \pdfximage external
> template?
There's this guy called Georg that does amazing things in a spare 10
minutes...
> I will apply the patch shortly.
> Georg
--
Angus
Re: Graphics files with spaces again!
Angus Leeming wrote:
> Ok, the problem is that ChangeExtension calls os::internal_path
> internally, so the \ characters here are converted to / ones:
> path = ChangeExtension("\\string\"" + base + "\\string\"", ext);
Attached is the equivalent patch for 1.4. Note that I also changed the
external inset where it made sense. This quoting business does not play
well with the external inset, since it may require to add the extension,
but IMO we should ignore that.
BTW, I was not very successful with my pdftex bug report:
http://sarovar.org/tracker/?func=detail&atid=493&aid=377&group_id=106
Does somebody have the time to create a \pdfximage external template?
I will apply the patch shortly.
GeorgIndex: src/support/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/ChangeLog,v
retrieving revision 1.352
diff -u -p -r1.352 ChangeLog
--- src/support/ChangeLog 5 Jul 2005 09:01:51 - 1.352
+++ src/support/ChangeLog 8 Jul 2005 14:57:17 -
@@ -1,3 +1,7 @@
+2005-07-08 Georg Baum <[EMAIL PROTECTED]>
+
+ * filetools.[Ch] (latex_path): add exclude_extension argument
+
2005-07-05 Jürgen Spitzmüller <[EMAIL PROTECTED]>
* lyxtime.[Ch]: two new functions formatted_time, which return
Index: src/support/filetools.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/filetools.C,v
retrieving revision 1.211
diff -u -p -r1.211 filetools.C
--- src/support/filetools.C 21 Jun 2005 09:01:41 - 1.211
+++ src/support/filetools.C 8 Jul 2005 14:57:20 -
@@ -82,14 +82,21 @@ bool IsSGMLFilename(string const & filen
}
-string const latex_path(string const & original_path)
+string const latex_path(string const & original_path, bool exclude_extension)
{
string path = subst(original_path, "\\", "/");
path = subst(path, "~", "\\string~");
if (path.find(' ') != string::npos)
// We can't use '"' because " is sometimes active (e.g. if
// babel is loaded with the "german" option)
- path = "\\string\"" + path + "\\string\"";
+ if (exclude_extension) {
+ string const base = ChangeExtension(path, string());
+ string const ext = GetExtension(path);
+ // ChangeExtension calls os::internal_path internally
+ // so don't use it to re-add the extension.
+ path = "\\string\"" + base + "\\string\"." + ext;
+ } else
+ path = "\\string\"" + path + "\\string\"";
return path;
}
Index: src/support/filetools.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/filetools.h,v
retrieving revision 1.64
diff -u -p -r1.64 filetools.h
--- src/support/filetools.h 26 Apr 2005 11:12:20 - 1.64
+++ src/support/filetools.h 8 Jul 2005 14:57:21 -
@@ -77,12 +77,10 @@ bool IsLyXFilename(std::string const & f
bool IsSGMLFilename(std::string const & filename);
/** Returns the path of a library data file.
- Search the file name.ext in the subdirectory dir of
- \begin{enumerate}
-\item user_lyxdir
-\item build_lyxdir (if not empty)
-\item system_lyxdir
- \end{enumerate}
+Search the file name.ext in the subdirectory dir of
+ -# user_lyxdir
+ -# build_lyxdir (if not empty)
+ -# system_lyxdir
The third parameter `ext' is optional.
*/
std::string const LibFileSearch(std::string const & dir, std::string const & name,
@@ -110,12 +108,18 @@ std::string const LibScriptSearch(std::s
* Manipulates @c path into a form suitable for inclusion in a LaTeX
* document.
* If @c path contains LaTeX special characters, these are escaped.
- * Eg, '~' -> '\string~'
+ * Eg, '~' -> '\\string~'
* If @c path contains spaces, then the returned path is enclosed in
* "-quotes. This last fix will lead to successful compiliation of the
* LaTeX file only if a sufficiently modern LaTeX compiler is used.
+ * If @c exclude_extension is true the extension is left outside the quotes.
+ * This is needed for pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
+ * (format=pdflatex 2005.4.11) in combination with
+ * pdftex.def 2002/06/19 v0.03k graphics/color for pdftex:
+ * It does not recognize the file extension if it is inside the quotes.
*/
-std::string const latex_path(std::string const & path);
+std::string const latex_path(std::string const & path,
+ bool exclude_extension = false)
/// Substitutes active latex characters with underscores in filename
std::string const MakeLatexName(std::string const & file);
Index: src/insets/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.1159
diff -u -p -r1.1159 ChangeLog
--- src/insets/ChangeLog 7 Jul 2005 10:51:57 - 1.1159
+++ src/insets/ChangeLog 8 Jul 2005 14:57:38 -
@@ -1,3 +1,11 @@
+2005-07-08 Georg Baum <[EMAIL PROTECTED]>
+
+ * ExternalSupport.C (subs
Re: Graphics files with spaces again!
Angus Leeming wrote:
Ok, the problem is that ChangeExtension calls os::internal_path
internally, so the \ characters here are converted to / ones:
path = ChangeExtension("\\string\"" + base + "\\string\"", ext);
I'm compiling the version of latex_path below and will report back in
the morning whether it succeeded.
It did. I've just uploaded version 20 of the pre-release of LyX 1.3.6 for
Windows to the wiki. It contains this fix and the key press fixes that the
Qt/Win Free people backported from Qt 4.0. IMO LyX 1.3.6 is in pretty good
shape on Windows.
Angus
Re: Graphics files with spaces again!
Angus Leeming wrote:
Can you see why it doesn't work:
\begin{flushleft}\includegraphics[%
width=0.9\columnwidth,
height=0.5\columnwidth]{/string"C:/Documents and Settings/Angus/Local
Settings/Temp/lyx_tmpdir5900a04256/lyx_tmpbuf0/J__MinSYS_home_Angus_ekkehart2_im_ages_picture/string".eps}\end{flushleft}
Hint: how do you spell '\string"' ?
Looking at the code, I can see no reason why this is happening. However,
I've added some braces to the if-blocks in latex_path, just in case it's
something stupid. I've also added some extra debug output.
Ok, the problem is that ChangeExtension calls os::internal_path internally,
so the \ characters here are converted to / ones:
path = ChangeExtension("\\string\"" + base + "\\string\"", ext);
I'm compiling the version of latex_path below and will report back in the
morning whether it succeeded.
Angus
string const latex_path(string const & original_path,
bool exclude_extension)
{
string path = subst(original_path, "~", "\\string~");
if (path.find(' ') != string::npos) {
// We can't use '"' because " is sometimes active (e.g. if
// babel is loaded with the "german" option)
if (exclude_extension) {
string const base = ChangeExtension(path, string());
string const ext = GetExtension(path);
// ChangeExtension calls os::internal_path internally
// so don't use it to re-add the extension.
path = "\\string\"" + base + "\\string\"." + ext;
} else {
path = "\\string\"" + path + "\\string\"";
}
}
return path;
}
Re: Graphics files with spaces again!
Angus Leeming wrote:
Georg Baum wrote:
Angus Leeming wrote:
Than please commit it and I'll fire up the Windows box.
Done. I really hope that it works now :-) If it does, I'll prepare a
similar patch for 1.4.
I'll try and find some time this evening to compile it and the latest
Qt/Win Free which should fix key handling issues on Windows too.
Can you see why it doesn't work:
\begin{flushleft}\includegraphics[%
width=0.9\columnwidth,
height=0.5\columnwidth]{/string"C:/Documents and Settings/Angus/Local
Settings/Temp/lyx_tmpdir5900a04256/lyx_tmpbuf0/J__MinSYS_home_Angus_ekkehart2_im_ages_picture/string".eps}\end{flushleft}
Hint: how do you spell '\string"' ?
Looking at the code, I can see no reason why this is happening. However,
I've added some braces to the if-blocks in latex_path, just in case it's
something stupid. I've also added some extra debug output.
Am currently recompiling and will test thereafter.
Angus
Re: Graphics files with spaces again!
Georg Baum wrote: > Angus Leeming wrote: >> Than please commit it and I'll fire up the Windows box. > Done. I really hope that it works now :-) If it does, I'll prepare a > similar patch for 1.4. I'll try and find some time this evening to compile it and the latest Qt/Win Free which should fix key handling issues on Windows too. -- Angus
Re: Graphics files with spaces again!
Angus Leeming wrote: > Than please commit it and I'll fire up the Windows box. Done. I really hope that it works now :-) If it does, I'll prepare a similar patch for 1.4. Georg
Re: Graphics files with spaces again!
Georg Baum wrote:
>> Don't we therefore need:
>> \includegraphics{\string"my dir/my picture\string".png}
> Yes. And the patch should exactly do that! If it does not, please shout!
Than please commit it and I'll fire up the Windows box.
--
Angus
Re: Graphics files with spaces again!
Angus Leeming wrote:
> Hm. I read this as outputting
> \includegraphics{\string"my dir/my picture\string"}
No. The magic happens in latex_path: strip extension, add quotes, add
extension.
> I thought that missing out the extension would break latex?
Yes.
> Don't we
> therefore need:
> \includegraphics{\string"my dir/my picture\string".png}
Yes. And the patch should exactly do that! If it does not, please shout!
Georg
Re: Graphics files with spaces again!
Georg Baum wrote:
> Conclusion: We can't make spaces work with pdfetex from tetex, but we can
> support them on miktex. Therefore I propose the following patch for 1.3.6
> (I'll send a similar one for 1.4 if this is OK).
Hm. I read this as outputting
\includegraphics{\string"my dir/my picture\string"}
I thought that missing out the extension would break latex? Don't we
therefore need:
\includegraphics{\string"my dir/my picture\string".png}
--
Angus
Re: Graphics files with spaces again!
Am Donnerstag, 30. Juni 2005 11:23 schrieb Angus Leeming:
> the attached .tex file can be compiled with pdflatex here (MikTeX). The
> latex compiler is happy with the equivalent .eps ending to
> ...picture\string".png}
>
> Of course, this is a doctored file because current cvs outputs
> ...picture.png\string"} which pdflatex certainly doesn't like although
the
> latex compiler is perfectly happy with the equivalent .eps version.
I still don't understand why that is the case. The error message comes
from graphics.sty, and dvips.def and pdftex.def use the same utility
routines to determine the extension.
> You tell me that your teTeX 3.0 version of pdflatex likes the second
> flavour but not the first?
No, that was a misunderstanding. It likes neither the first nor the
second, but with different error messages. Meanwhile I have found the
reason for the differences between miktex and tetex (reading the source
helps): The file texk/web2c/pdftex/writeimg.c of pdftex contains this
snippet
#ifdef WIN32
/* unquote file name */
if (*cur_file_name == '"') {
char *p = cur_file_name;
char *q = cur_file_name;
while (p && *p) {
*q = (*p == '"' ? *(++p) : *p);
p++, q++;
}
*q = '\0';
}
fprintf(stderr, " %s\n", cur_file_name);
#endif
commenting the ifdef and recompiling (I got the tetex source from
http://cvs.debian.org/?cvsroot=tetex) produced a pdfetex binary that
understands the first flavor. I'll file that as a bug, since spaces in
filenames are not windows specific.
BTW, the code above translates '"abc""d"' to 'abc"d'. I don't know if this
is a feature or a bug ;-) At least it allows us to include files with "
in the name (although we get a warning
LaTeX Warning: File `"abc""d".pdf' not found on input line 7.
but the file appears in the output).
Conclusion: We can't make spaces work with pdfetex from tetex, but we can
support them on miktex. Therefore I propose the following patch for 1.3.6
(I'll send a similar one for 1.4 if this is OK).
Georg
diff -p -r -U 3 -X excl.tmp lyx-1.3-clean/src/insets/ChangeLog lyx-1.3-cvs/src/insets/ChangeLog
--- lyx-1.3-clean/src/insets/ChangeLog 2005-06-20 21:06:27.0 +0200
+++ lyx-1.3-cvs/src/insets/ChangeLog 2005-06-21 20:44:51.0 +0200
@@ -1,3 +1,7 @@
+2005-06-21 Georg Baum <[EMAIL PROTECTED]>
+
+ * insetgraphics.C (latex): Put the extension outside the quotes
+
2005-06-18 Georg Baum <[EMAIL PROTECTED]>
* insetgraphics.C (prepareFile): Don't strip the extension, because
diff -p -r -U 3 -X excl.tmp lyx-1.3-clean/src/insets/insetgraphics.C lyx-1.3-cvs/src/insets/insetgraphics.C
--- lyx-1.3-clean/src/insets/insetgraphics.C 2005-06-20 21:06:30.0 +0200
+++ lyx-1.3-cvs/src/insets/insetgraphics.C 2005-06-21 20:40:41.0 +0200
@@ -777,7 +859,7 @@ int InsetGraphics::latex(Buffer const *b
buf->filePath()),
m_buffer->filePath());
}
- latex_str += latex_path(fname);
+ latex_str += latex_path(fname, true);
}
latex_str += '}' + after;
diff -p -r -U 3 -X excl.tmp lyx-1.3-clean/src/support/ChangeLog lyx-1.3-cvs/src/support/ChangeLog
--- lyx-1.3-clean/src/support/ChangeLog 2005-06-11 13:14:06.0 +0200
+++ lyx-1.3-cvs/src/support/ChangeLog 2005-06-21 20:42:47.0 +0200
@@ -1,3 +1,7 @@
+2005-06-21 Georg Baum <[EMAIL PROTECTED]>
+
+ * filetools.[Ch] (latex_path): add exclude_extension argument
+
2005-06-21 Georg Baum <[EMAIL PROTECTED]>
* filetools.C (latex_path): protect " with \string since it may be
diff -p -r -U 3 -X excl.tmp lyx-1.3-clean/src/support/filetools.C lyx-1.3-cvs/src/support/filetools.C
--- lyx-1.3-clean/src/support/filetools.C 2005-06-11 13:14:07.0 +0200
+++ lyx-1.3-cvs/src/support/filetools.C 2005-06-21 20:38:28.0 +0200
@@ -91,13 +91,20 @@ bool IsSGMLFilename(string const & filen
}
-string const latex_path(string const & original_path)
+string const latex_path(string const & original_path, bool exclude_extension)
{
string path = subst(original_path, "~", "\\string~");
if (path.find(' ') != string::npos)
// We can't use '"' because " is sometimes active (e.g. if
// babel is loaded with the "german" option)
- path = "\\string\"" + path + "\\string\"";
+ if (exclude_extension) {
+ string const base = ChangeExtension(path, string());
+ string const ext = GetExtension(path);
+ path = ChangeExtension(
+"\\string\"" + base + "\\string\"", ext);
+ } else
+
+ path = "\\string\"" + path + "\\string\"";
return path;
}
diff -p -r -U 3 -X excl.tmp lyx-1.3-clean/src/support/filetools.h lyx-1.3-cvs/src/support/filetools.h
--- lyx-1.3-clean/src/support/filetools.h 2005-06-11 13:14:07.0 +0200
+++ lyx-1.3-cvs/src/support/filetools.h 2005-06-21 20:38:40.0 +0200
@@ -146,8 +146,13 @@ bool PutEnvPath(string const & envstr);
* If @c path contains spaces, then the returned path is enclosed in
* "-quotes. This last fix will lead to successful compiliation of the
*
Re: Graphics files with spaces again!
Georg Baum wrote: I attach my version of graphicx.sty. Could you try it bei Dir? I will do so tomorrow evening when I get to the machine with tetex 3.0 again. Thank you. From our previuos investigations I know that (according to the version numbers) our versions of pdfetex, graphicx.sty and pdftex.def are exactly the same. The only reason for differences that I could imagine is that either Debian or MikTeX applied some patches to one of the files involved. Could you please send me your version of pdftex.def, too? See graphics.tar.bz2 attached in a reply to JMarc in this thread. Or, if you are impatient: Extract the files from the debian package that I use: http://packages.debian.org/experimental/tex/tetex-base and try it yourself. Me? Impatient? Never! Angus
Re: Graphics files with spaces again!
Angus Leeming wrote: > You tell me that your teTeX 3.0 version of pdflatex likes the second > flavour but not the first? Is that a function of the compiler or of the > graphicx.sty? I don't know. > $ pdflatex --version > MiKTeX-pdfetex 2.4.1862 (1.21a) (MiKTeX 2.4) > Copyright (C) 1982 D. E. Knuth, (C) 1996-2002 Han The Thanh > TeX is a trademark of the American Mathematical Society. > > I attach my version of graphicx.sty. > > Could you try it bei Dir? I will do so tomorrow evening when I get to the machine with tetex 3.0 again. >From our previuos investigations I know that (according to the version numbers) our versions of pdfetex, graphicx.sty and pdftex.def are exactly the same. The only reason for differences that I could imagine is that either Debian or MikTeX applied some patches to one of the files involved. Could you please send me your version of pdftex.def, too? Or, if you are impatient: Extract the files from the debian package that I use: http://packages.debian.org/experimental/tex/tetex-base and try it yourself. Georg
Re: Graphics files with spaces again!
Jean-Marc Lasgouttes wrote:
Angus> Jean-Marc Lasgouttes wrote: You tell me that your teTeX 3.0
Angus> version of pdflatex likes the second flavour but not the first?
Angus> Is that a function of the compiler or of the graphicx.sty?
I guess the difference is more likely to be in pdftex.def, which is
supposed to be the graphics driver. What happens if you set
explicitely the graphics driver to pdftex?
Angus> How do I do that?
Pass it as option to the graphicx package. I wonder whether we should
pass a different option to graphicx depending on the flavor of LaTeX
we use.
pdflatex is happy with this, but isn't happy if .png is moved inside of
\string". (No known extension .png".) For info, I attach the entire MiKTeX
tex/latex/graphics directory.
Angus
\documentclass[german]{article}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage[pdftex]{graphicx}
\makeatletter
\usepackage{babel}
\makeatother
\begin{document}
%
\begin{figure}
\begin{flushleft}\includegraphics[%
width=0.9\columnwidth,
height=0.5\columnwidth]{\string"im ages/picture\string".png}%
\end{flushleft}
\caption{\noindent Text}
\end{figure}
\end{document}
graphics.tar.bz2
Description: Binary data
Re: Graphics files with spaces again!
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Jean-Marc Lasgouttes wrote: You tell me that your teTeX 3.0 Angus> version of pdflatex likes the second flavour but not the first? Angus> Is that a function of the compiler or of the graphicx.sty? >> I guess the difference is more likely to be in pdftex.def, which is >> supposed to be the graphics driver. What happens if you set >> explicitely the graphics driver to pdftex? Angus> How do I do that? Pass it as option to the graphicx package. I wonder whether we should pass a different option to graphicx depending on the flavor of LaTeX we use. JMarc
Re: Graphics files with spaces again!
Jean-Marc Lasgouttes wrote: Angus> You tell me that your teTeX 3.0 version of pdflatex likes the Angus> second flavour but not the first? Is that a function of the Angus> compiler or of the graphicx.sty? I guess the difference is more likely to be in pdftex.def, which is supposed to be the graphics driver. What happens if you set explicitely the graphics driver to pdftex? How do I do that? Angus
Re: Graphics files with spaces again!
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> You tell me that your teTeX 3.0 version of pdflatex likes the Angus> second flavour but not the first? Is that a function of the Angus> compiler or of the graphicx.sty? I guess the difference is more likely to be in pdftex.def, which is supposed to be the graphics driver. What happens if you set explicitely the graphics driver to pdftex? JMarc
Re: Graphics path with ":"
On Tue, May 31, 2005 at 11:12:26AM +0200, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Reading http://wiki.lyx.org/LaTeX/FilesWithSpecialChars and > Angus> http://wiki.lyx.org/uploads/LaTeX/FilesWithSpecialChars/filenames.tex, > Angus> I don't see why a ':' in a file name won't work, but you're the > Angus> one using this stuff... > > I guess ':' is a problem in a windows file name if it is not the drive > separator. 'Problem' is the wrong word. They serve a purpose IIRC. Try writing and reading to a.txt:1. Andre'
Re: Graphics path with ":"
Michael Schmitt wrote: Angus Leeming wrote: In src/frontends/controllers/helper_funcs.C, try removing the ':' from Please report back if LaTeX is happy. LaTeX is happy and I am happy, too :-) Then I'll commit the patch... Done. What astonishes me is the fact that LyX 1.4 works without a patch. Maybe it converts paths before the character check... Perhaps you aren't looking hard enough. The check is in the input widget in 1.4.x. The first time you input an invalid file name you'll get a dialog popping up to tell you so, but thereafter it won't. Instead, the input widget's label should go red and the dialog OK,Apply buttons will be disabled. Angus
Re: Graphics path with ":"
Angus Leeming wrote: In src/frontends/controllers/helper_funcs.C, try removing the ':' from Please report back if LaTeX is happy. LaTeX is happy and I am happy, too :-) What astonishes me is the fact that LyX 1.4 works without a patch. Maybe it converts paths before the character check... Regards, Michael
Re: Graphics path with ":"
Jean-Marc Lasgouttes wrote: > Angus> One thing that I have noticed (not a bug, but an inconsistency) > Angus> is that in the Preferences dialog, the Paths pane displays all > Angus> paths in UNIX style. This looks a little odd because at the > Angus> bottom of the list is the "prepend_path" variable which is > Angus> displayed as "C:\foo\bar;C:\bar\baz". > > Angus> Do you think that we should pass the other paths through > Angus> (in,ex}ternal_path() ? > > We should probably. But in which form should we store them? lyxrc.defaults/preferences: external_path. Convert to internal_path in lyxrc::read() and to external_path in lyxrc::write(). -- Angus
Re: Graphics path with ":"
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> One thing that I have noticed (not a bug, but an inconsistency) Angus> is that in the Preferences dialog, the Paths pane displays all Angus> paths in UNIX style. This looks a little odd because at the Angus> bottom of the list is the "prepend_path" variable which is Angus> displayed as "C:\foo\bar;C:\bar\baz". Angus> Do you think that we should pass the other paths through Angus> (in,ex}ternal_path() ? We should probably. But in which form should we store them? JMarc
Re: Graphics path with ":"
Jean-Marc Lasgouttes wrote: > Angus> Reading http://wiki.lyx.org/LaTeX/FilesWithSpecialChars and > Angus> http://wiki.lyx.org/uploads/LaTeX/FilesWithSpecialChars/filenames.tex, > Angus> I don't see why a ':' in a file name won't work, but you're the > Angus> one using this stuff... > > I guess ':' is a problem in a windows file name if it is not the drive > separator. Not from a LaTeX point of view. The OS will complain that such a file name is illegal and that the file can't exist. I don't think that we need to do anything special to handle such situations. One thing that I have noticed (not a bug, but an inconsistency) is that in the Preferences dialog, the Paths pane displays all paths in UNIX style. This looks a little odd because at the bottom of the list is the "prepend_path" variable which is displayed as "C:\foo\bar;C:\bar\baz". Do you think that we should pass the other paths through (in,ex}ternal_path() ? -- Angus
Re: Graphics path with ":"
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Reading http://wiki.lyx.org/LaTeX/FilesWithSpecialChars and Angus> http://wiki.lyx.org/uploads/LaTeX/FilesWithSpecialChars/filenames.tex, Angus> I don't see why a ':' in a file name won't work, but you're the Angus> one using this stuff... I guess ':' is a problem in a windows file name if it is not the drive separator. JMarc
Re: Graphics path with ":"
Michael Schmitt wrote:
> Angus,
>
> I tried to insert a graphics which is located in directory
> C:\blabla\blabla. However, LyX 1.3.6cvs complains about the path
> containing invalid character ":". Didn't this work before?
In src/frontends/controllers/helper_funcs.C, try removing the ':' from
string const get_invalid_chars_latex()
{
string invalid_chars("#$%{}()[]:\"^");
if (!lyxrc.tex_allows_spaces)
invalid_chars += ' ';
return invalid_chars;
}
Reading http://wiki.lyx.org/LaTeX/FilesWithSpecialChars and
http://wiki.lyx.org/uploads/LaTeX/FilesWithSpecialChars/filenames.tex, I
don't see why a ':' in a file name won't work, but you're the one using
this stuff...
Please report back if LaTeX is happy.
--
Angus
Re: graphics loading still jumping to top of doc
Alfredo Braunstein wrote: > > Garst R. Reese wrote: > > > It severly impacts scrolling thru a doc. > > Every time a grapic is loaded the cursor jumps to the the top of the > > document. > > Is it the top of the document or the cursor position? Top of document. > Does this solves it? > Yes. Thanks, Garst
Re: graphics loading still jumping to top of doc
Garst R. Reese wrote:
> It severly impacts scrolling thru a doc.
> Every time a grapic is loaded the cursor jumps to the the top of the
> document.
Regards, Alfredo
Is it the top of the document or the cursor position?
Does this solves it?
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.424
diff -u -p -u -r1.424 BufferView_pimpl.C
--- BufferView_pimpl.C 28 Aug 2003 07:41:10 - 1.424
+++ BufferView_pimpl.C 1 Sep 2003 20:12:46 -
@@ -656,7 +656,6 @@ void BufferView::Pimpl::update()
if (bv_->getLyXText()) {
// check needed to survive LyX startup
bv_->getLyXText()->redoCursor();
- fitCursor();
}
screen().redraw(*bv_);
}
Re: graphics loading still jumping to top of doc
Angus Leeming wrote: > Garst, could you expand further? I've just looked at the ChangeLogs My mistake. It was July 21, and that seems too early. G.
Re: graphics loading still jumping to top of doc
Garst R. Reese wrote: > If the ChangeLogs are any indication, this probably started with > Angus on Aug 21. > It severly impacts scrolling thru a doc. > Every time a grapic is loaded the cursor jumps to the the top of the > document. Garst, could you expand further? I've just looked at the ChangeLogs using the viewcvs interface and can see no entries at all from 21 August, let alone from me. Looked at ChangeLogs in src, src/insets and src/graphics. -- Angus
[PATCH] Re: graphics cache file path horkage
On Fri, May 30, 2003 at 02:24:22AM +0100, John Levon wrote:
> > I believe we should *always* store an absolute path at
> > runtime. At save time, we can convert it to a relative path.
Fixed patch. It seems to work for me. It fixes the Save As bug.
Please please test.
john
p.s. sorry, no, I'm not taking maintainership of this code
Index: factory.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/factory.C,v
retrieving revision 1.29
diff -u -p -r1.29 factory.C
--- factory.C 22 May 2003 10:40:55 - 1.29
+++ factory.C 30 May 2003 02:15:38 -
@@ -211,8 +211,7 @@ Inset * createInset(FuncRequest const &
InsetGraphicsParams igp;
InsetGraphicsMailer::string2params(cmd.argument, igp);
InsetGraphics * inset = new InsetGraphics;
- string const fpath = cmd.view()->buffer()->filePath();
- inset->setParams(igp, fpath);
+ inset->setParams(igp);
return inset;
} else if (name == "include") {
Index: insets/insetgraphics.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetgraphics.C,v
retrieving revision 1.176
diff -u -p -r1.176 insetgraphics.C
--- insets/insetgraphics.C 28 May 2003 23:09:14 - 1.176
+++ insets/insetgraphics.C 30 May 2003 02:15:44 -
@@ -182,7 +182,7 @@ void InsetGraphics::Cache::update(string
lyx::Assert(!file_with_path.empty());
string const path = OnlyPath(file_with_path);
- loader.reset(file_with_path, parent_.params().as_grfxParams(path));
+ loader.reset(file_with_path, parent_.params().as_grfxParams());
}
@@ -192,19 +192,20 @@ InsetGraphics::InsetGraphics()
{}
-InsetGraphics::InsetGraphics(InsetGraphics const & ig,
-string const & filepath)
+#warning I have zero idea about the trackable()
+InsetGraphics::InsetGraphics(InsetGraphics const & ig)
: Inset(ig),
+ boost::signals::trackable(ig),
graphic_label(uniqueID()),
cache_(new Cache(*this))
{
- setParams(ig.params(), filepath);
+ setParams(ig.params());
}
-Inset * InsetGraphics::clone(Buffer const & buffer) const
+Inset * InsetGraphics::clone(Buffer const &) const
{
- return new InsetGraphics(*this, buffer.filePath());
+ return new InsetGraphics(*this);
}
@@ -222,8 +223,7 @@ dispatch_result InsetGraphics::localDisp
InsetGraphicsParams p;
InsetGraphicsMailer::string2params(cmd.argument, p);
if (!p.filename.empty()) {
- string const filepath = cmd.view()->buffer()->filePath();
- setParams(p, filepath);
+ setParams(p);
cmd.view()->updateInset(this);
}
return DISPATCHED;
@@ -327,18 +327,6 @@ BufferView * InsetGraphics::view() const
void InsetGraphics::draw(BufferView * bv, LyXFont const & font,
int baseline, float & x) const
{
- // MakeAbsPath returns params().filename unchanged if it absolute
- // already.
- string const file_with_path =
- MakeAbsPath(params().filename, bv->buffer()->filePath());
-
- // A 'paste' operation creates a new inset with the correct filepath,
- // but then the 'old' inset stored in the 'copy' operation is actually
- // added to the buffer.
- // Thus, we should ensure that the filepath is correct.
- if (file_with_path != cache_->loader.filename())
- cache_->update(file_with_path);
-
cache_->view = bv->owner()->view();
int oasc = cache_->old_ascent;
@@ -408,10 +396,10 @@ Inset::EDITABLE InsetGraphics::editable(
}
-void InsetGraphics::write(Buffer const *, ostream & os) const
+void InsetGraphics::write(Buffer const * buf, ostream & os) const
{
os << "Graphics\n";
- params().Write(os);
+ params().Write(os, buf->filePath());
}
@@ -420,15 +408,15 @@ void InsetGraphics::read(Buffer const *
string const token = lex.getString();
if (token == "Graphics")
- readInsetGraphics(lex);
+ readInsetGraphics(lex, buf->filePath());
else
lyxerr[Debug::GRAPHICS] << "Not a Graphics inset!\n";
- cache_->update(MakeAbsPath(params().filename, buf->filePath()));
+ cache_->update(params().filename);
}
-void InsetGraphics::readInsetGraphics(LyXLex & lex)
+void InsetGraphics::readInsetGraphics(LyXLex & lex, string const & bufpath)
{
bool finished = false;
@@ -455,7 +443,7 @@ void InsetGraphics::readInsetGraphics(Ly
// TODO: Possibly open up a dialog?
}
else {
- if (! param
Re: graphics cache file path horkage
On Fri, May 30, 2003 at 01:49:28AM +0100, John Levon wrote:
> I believe we should *always* store an absolute path at
> runtime. At save time, we can convert it to a relative path.
Here's an attempt at a patch. Not tested
john
Index: insetgraphics.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetgraphics.C,v
retrieving revision 1.176
diff -u -p -r1.176 insetgraphics.C
--- insetgraphics.C 28 May 2003 23:09:14 - 1.176
+++ insetgraphics.C 30 May 2003 01:21:21 -
@@ -182,7 +182,7 @@ void InsetGraphics::Cache::update(string
lyx::Assert(!file_with_path.empty());
string const path = OnlyPath(file_with_path);
- loader.reset(file_with_path, parent_.params().as_grfxParams(path));
+ loader.reset(file_with_path, parent_.params().as_grfxParams());
}
@@ -192,19 +192,20 @@ InsetGraphics::InsetGraphics()
{}
-InsetGraphics::InsetGraphics(InsetGraphics const & ig,
-string const & filepath)
+#warning I have zero idea about the trackable()
+InsetGraphics::InsetGraphics(InsetGraphics const & ig)
: Inset(ig),
+ boost::signals::trackable(ig),
graphic_label(uniqueID()),
cache_(new Cache(*this))
{
- setParams(ig.params(), filepath);
+ setParams(ig.params());
}
-Inset * InsetGraphics::clone(Buffer const & buffer) const
+Inset * InsetGraphics::clone(Buffer const &) const
{
- return new InsetGraphics(*this, buffer.filePath());
+ return new InsetGraphics(*this);
}
@@ -222,8 +223,7 @@ dispatch_result InsetGraphics::localDisp
InsetGraphicsParams p;
InsetGraphicsMailer::string2params(cmd.argument, p);
if (!p.filename.empty()) {
- string const filepath = cmd.view()->buffer()->filePath();
- setParams(p, filepath);
+ setParams(p);
cmd.view()->updateInset(this);
}
return DISPATCHED;
@@ -327,18 +327,6 @@ BufferView * InsetGraphics::view() const
void InsetGraphics::draw(BufferView * bv, LyXFont const & font,
int baseline, float & x) const
{
- // MakeAbsPath returns params().filename unchanged if it absolute
- // already.
- string const file_with_path =
- MakeAbsPath(params().filename, bv->buffer()->filePath());
-
- // A 'paste' operation creates a new inset with the correct filepath,
- // but then the 'old' inset stored in the 'copy' operation is actually
- // added to the buffer.
- // Thus, we should ensure that the filepath is correct.
- if (file_with_path != cache_->loader.filename())
- cache_->update(file_with_path);
-
cache_->view = bv->owner()->view();
int oasc = cache_->old_ascent;
@@ -408,10 +396,10 @@ Inset::EDITABLE InsetGraphics::editable(
}
-void InsetGraphics::write(Buffer const *, ostream & os) const
+void InsetGraphics::write(Buffer const * buf, ostream & os) const
{
os << "Graphics\n";
- params().Write(os);
+ params().Write(os, buf->filePath());
}
@@ -420,15 +408,15 @@ void InsetGraphics::read(Buffer const *
string const token = lex.getString();
if (token == "Graphics")
- readInsetGraphics(lex);
+ readInsetGraphics(lex, buf->filePath());
else
lyxerr[Debug::GRAPHICS] << "Not a Graphics inset!\n";
- cache_->update(MakeAbsPath(params().filename, buf->filePath()));
+ cache_->update(params().filename);
}
-void InsetGraphics::readInsetGraphics(LyXLex & lex)
+void InsetGraphics::readInsetGraphics(LyXLex & lex, string const & bufpath)
{
bool finished = false;
@@ -455,7 +443,7 @@ void InsetGraphics::readInsetGraphics(Ly
// TODO: Possibly open up a dialog?
}
else {
- if (! params_.Read(lex, token))
+ if (!params_.Read(lex, token, bufpath))
lyxerr << "Unknown token, " << token << ", skipping."
<< std::endl;
}
@@ -518,17 +506,13 @@ string const InsetGraphics::prepareFile(
{
// LaTeX can cope if the graphics file doesn't exist, so just return the
// filename.
- string const orig_file = params().filename;
- string orig_file_with_path =
- MakeAbsPath(orig_file, buf->filePath());
- lyxerr[Debug::GRAPHICS] << "[InsetGraphics::prepareFile] orig_file = "
- << orig_file << "\n\twith path: "
- << orig_file_with_path << endl;
+ string orig_file = params().filename;
+ string const rel_file = MakeRelPath(orig_file, buf->filePath());
- if (!IsFileReadable(orig_file_with_path))
- return orig_file;
Re: Graphics Loader
Angus Leeming wrote: > Ok, so: > std::queue tmp; > swap(bucket1_, tmp; > Still no need to pollute the class interface... You are right (as always). Done, thanks. I'll try to send something to the list this evening. Right now I need to get some real life work done... In the meantime, can anyone try the last patch I send and check for useability etc? And there's still this startup ordering thing, also. Bye, Alfredo
Re: Graphics Loader
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> There is still no need to have bucket2_ as a class member...
>>
>> void LoaderQueue::emptyBucket()
>> {
>> cout << "emptying bucket" << endl;
>> std::queue tmp = bucket1_;
>> while (!tmp.empty()) {
>> addToQueue(tmp.front());
>> tmp.pop();
>> }
>> }
>
> Humm... I think that this doesn't cut it, you cannot copy bucket1_ without
> locking it (touch() can be accessing it at the same time, you can end up
> with a partially updated queue). If we use swap(), then is merely swapping
> pointers, that is supposed to be threads-safe (apart from being faster).
> But I'm not at all a threads guru (first application really)... So correct
> if I'm wrong.
Ok, so:
std::queue tmp;
swap(bucket1_, tmp;
Still no need to pollute the class interface...
Thanks for the info about threads.
--
Angus
Re: Graphics Loader
Angus Leeming wrote:
> There is still no need to have bucket2_ as a class member...
>
> void LoaderQueue::emptyBucket()
> {
> cout << "emptying bucket" << endl;
> std::queue tmp = bucket1_;
> while (!tmp.empty()) {
> addToQueue(tmp.front());
> tmp.pop();
> }
> }
Humm... I think that this doesn't cut it, you cannot copy bucket1_ without
locking it (touch() can be accessing it at the same time, you can end up
with a partially updated queue). If we use swap(), then is merely swapping
pointers, that is supposed to be threads-safe (apart from being faster).
But I'm not at all a threads guru (first application really)... So correct
if I'm wrong.
> Comment your code. Add a blurb to the top giving the basic philosophy. Add
> files LoaderQueue.[Ch]. Remove GraphicsLoader::checkedStart or whatever
> it's called. Remove GraphicsSupport.[Ch]. Keep going!
Will try to. Thanks, Angus!
Re: Graphics Loader
Andre Poenitz wrote: > On Thu, Feb 20, 2003 at 02:15:06PM +0100, Alfredo Braunstein wrote: >> > It doesn't depend on BufferView. Why not make it a singleton class? >> >> Sure... what's a singleton class? > > Just put it into a class and create just one object of it. > [The rest is rather ideology] See GraphicsCache.[Ch]. Quite neat really. -- Angus
Re: Graphics Loader
Alfredo Braunstein wrote:
>> exit to the method. In fact why not:
>> +void LoaderQueue::emptyBucket()
>> +{
>> + cout << "emptying bucket" << endl;
>> + while (! bucket1_.empty()) {
>> + addToQueue(bucket1_.front());
>> + bucket1_.pop();
>> + }
>> +}
>
> This is to avoid having to lock the data. In this way we have always a
> bucket ready for input that we are not touching. Is it reasonable?
> It remembers me when it's raining inside my house because a hole in the
> roof. Instead of emptying the bucket in a hurry risking to get the floor
> wet, I have an aditional empty bucket ready and I swap them, and then go
> calmly to empty the unused one.
There is still no need to have bucket2_ as a class member...
void LoaderQueue::emptyBucket()
{
cout << "emptying bucket" << endl;
std::queue tmp = bucket1_;
while (!tmp.empty()) {
addToQueue(tmp.front());
tmp.pop();
}
}
>> I'm a bit confused by cache_set_ and cache_queue_. Could you help me?
>>
>
> We need a queue with 'reprioritization'. That's it: if a new entry is
> added, then it is added to the top. If the entry was already there, then
> we have to move it to the top (or equivalently, remove it and add it to
> the top). This queue is implemented as a list and is called cache_queue_.
> In order to make faster the insertion in the 'don't have it' case (the
> most common?), I've added a set with the same entries to check if the new
> entry is not already on the queue. If it's not, then qe have only to add
> it tot the top (no checking). Maybe this set part does not worst it?
>
> This is the simplest implementation I've could think. Does it sounds
> reasonable?
Yes.
Comment your code. Add a blurb to the top giving the basic philosophy. Add
files LoaderQueue.[Ch]. Remove GraphicsLoader::checkedStart or whatever
it's called. Remove GraphicsSupport.[Ch]. Keep going!
--
Angus
Re: Graphics Loader
On Thu, Feb 20, 2003 at 02:15:06PM +0100, Alfredo Braunstein wrote: > > It doesn't depend on BufferView. Why not make it a singleton class? > > Sure... what's a singleton class? Just put it into a class and create just one object of it. [The rest is rather ideology] Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Graphics Loader
Angus Leeming wrote:
> It doesn't depend on BufferView. Why not make it a singleton class?
Sure... what's a singleton class?
> bucket1_ is filled with Cache::ItemPtrs to be dealt with by
> LoaderQueue::touch.
>
> The timer calls LoaderQueue::loadNext every 100 ms.
>
> LoaderQueue::loadNext calls
> emptyBucket(), which:
> swap(bucket1_, bucket2_);
> Why is bucket2_ a class member. It is used only in
> LoaderQueue::emptyBucket() and is guaranteed to be empty on entry and on
> exit to the method. In fact why not:
> +void LoaderQueue::emptyBucket()
> +{
> + cout << "emptying bucket" << endl;
> + while (! bucket1_.empty()) {
> + addToQueue(bucket1_.front());
> + bucket1_.pop();
> + }
> +}
This is to avoid having to lock the data. In this way we have always a
bucket ready for input that we are not touching. Is it reasonable?
It remembers me when it's raining inside my house because a hole in the
roof. Instead of emptying the bucket in a hurry risking to get the floor
wet, I have an aditional empty bucket ready and I swap them, and then go
calmly to empty the unused one.
> LoaderQueue::addToQueue takes this Cache::ItemPtr and adds it to the queue
> of items to be processed, cache_queue_, if not already there.
>
> Why not:
> void LoaderQueue::addToQueue(Cache::ItemPtr & item)
> (Ie, pass by reference). It isn't a simple pointer and so will add
> overhead passing by value as you do now.
You are perfectly right, I though it was.
> Once cache_queue_ is initialised, loadNext instigates the actual loading
> of the Cache::ItemPtrs.
>
> I'm a bit confused by cache_set_ and cache_queue_. Could you help me?
>
We need a queue with 'reprioritization'. That's it: if a new entry is added,
then it is added to the top. If the entry was already there, then we have
to move it to the top (or equivalently, remove it and add it to the top).
This queue is implemented as a list and is called cache_queue_.
In order to make faster the insertion in the 'don't have it' case (the most
common?), I've added a set with the same entries to check if the new entry
is not already on the queue. If it's not, then qe have only to add it tot
the top (no checking). Maybe this set part does not worst it?
This is the simplest implementation I've could think. Does it sounds
reasonable?
Thanks, Alfredo
Re: Graphics Loader
Alfredo Braunstein wrote:
> A second option for LoaderQueue.
> I've left the previous interface untouched, but changed a little the
> implementation. Now touch() doesn't add directly the image pointer to the
> queue, but it adds it to an input bucket (implemented as a plain queue)
> without any checking and returns inmediately.
> Then on the 'threaded' method LoadNext we empty the input bucket into the
> queue, with all uniqueness and reprioritization checking.
> This implementation avoids completely having to lock the data, and so any
> posibility of losing time on the main thread.
> The startup time should be shorter also.
>
> I have to solve at least one problem: the graphics insets have
> startLoading called in document order, from first to last. Then they are
> added to the queue in inversed order, and start loading from last to
> first. Maybe we have to bypass this reprioritizing mechanism on startup
> somehow? Any clue on how to solve this please?
>
> (there are other remaining things if ever this gets incorporated: like to
> where the LoaderQueue class belongs (BufferView?).
It doesn't depend on BufferView. Why not make it a singleton class?
> Does it deserves its own file
Yes.
> PS: As before, please correct without mercy but being nice...
bucket1_ is filled with Cache::ItemPtrs to be dealt with by
LoaderQueue::touch.
The timer calls LoaderQueue::loadNext every 100 ms.
LoaderQueue::loadNext calls
emptyBucket(), which:
swap(bucket1_, bucket2_);
Why is bucket2_ a class member. It is used only in
LoaderQueue::emptyBucket() and is guaranteed to be empty on entry and on
exit to the method. In fact why not:
+void LoaderQueue::emptyBucket()
+{
+ cout << "emptying bucket" << endl;
+ while (! bucket1_.empty()) {
+ addToQueue(bucket1_.front());
+ bucket1_.pop();
+ }
+}
LoaderQueue::addToQueue takes this Cache::ItemPtr and adds it to the queue
of items to be processed, cache_queue_, if not already there.
Why not:
void LoaderQueue::addToQueue(Cache::ItemPtr & item)
(Ie, pass by reference). It isn't a simple pointer and so will add overhead
passing by value as you do now.
Once cache_queue_ is initialised, loadNext instigates the actual loading of
the Cache::ItemPtrs.
I'm a bit confused by cache_set_ and cache_queue_. Could you help me?
--
Angus
Re: Graphics Loader
Alfredo Braunstein wrote: > PS: using previews with current cvs, I get a strange behaviour. In a new > document, make a math inset (like... C-m 1 esc). Then Latex and dvipsk are > called twice. Does anyone else see it? Is it intended? Why? Yes I see it. No it's not. Don't know. -- Angus
Re: Graphics Loader
Angus Leeming wrote: > Actually, after I wrote this, I think that your code is perfect as it > is. No need for the isInsetVisible stuff or the 2 second pause at all. > > Moreover, if you modified GraphicsConverter as well so that it > created a queue of scripts to execute sequentially, as described > above, then we wouldn't run the risk of bringing down the system with > multiple expensive conversion codes running simultaneously. (The > complaint has been registered :-() > > The more I look at you code, the more I like it. It satisfies an > important 'feel good' criterion: it will result in a net reduction in > the number of lines of code (all of GraphicsSupport.[Ch] can go for > example). > > Super effort! > I feel all warm. Will try to work out the patch into an acceptable state, and then make a stab at the GraphicsConverter stuff. PS: using previews with current cvs, I get a strange behaviour. In a new document, make a math inset (like... C-m 1 esc). Then Latex and dvipsk are called twice. Does anyone else see it? Is it intended? Why? Thanks! Alfredo
Re: Graphics Loader
Alfredo Braunstein wrote: >> We have a nice ForkedCall class that emits a signal when the forked >> process ends. We could have a function processQueue() that pops a >> single item off the queue and forks a process with it. When it >> finishes, the ForkedCall emits a signal which LyX uses to start the >> loading process. This loading process could also call >> processQueue() to pop another item off the queue. > > Got it, thanks. Actually, after I wrote this, I think that your code is perfect as it is. No need for the isInsetVisible stuff or the 2 second pause at all. Moreover, if you modified GraphicsConverter as well so that it created a queue of scripts to execute sequentially, as described above, then we wouldn't run the risk of bringing down the system with multiple expensive conversion codes running simultaneously. (The complaint has been registered :-() The more I look at you code, the more I like it. It satisfies an important 'feel good' criterion: it will result in a net reduction in the number of lines of code (all of GraphicsSupport.[Ch] can go for example). Super effort! -- Angus
Re: Graphics Loader
Hi Angus, Angus Leeming wrote: > No, I thought you said that you posted it for examination only? It is in a working state. I meant the obvious: is not for applying to cvs (said mostly to cover my back with dignity if you rejected it in disgust :) >> If you scroll fast, then all insets not loaded >> yet will go down the queue, replaced by newly touched ones. >> And you don't need to check for visibility. > > I understand how it works. Nothing can be added to the queue whilst > loadNext is running. This is a threads limitation (in order to avoid clashes while accesing the same data). What I plan to do is to reduce to a minimum (the time to copy the data) the locking time, and make touch() to wait until unlocked. > However, I also disagree with your last statement above. I think it > would be 'better' is loadNext itself did what checkedLoading does > now; there really is no need at all to start loading/converting > graphics files that aren't going to be visible. (Retreating ashamed) It's mostly why I've started coding this: to avoid waiting for the previews to appear, (using idle time, i.e. without loading all them at startup). If this not desired, then I don't see a real reason for changing what there is now. It's working as intended, after all. > >> Sorry , failed completely to explain myself. What I wanted to say >> is: can we >> >> 1) Make avery redraw to redraw more than one screen (say 1 >> fullscreen up and down) to refresh. >> 2) Maybe call a redraw at startup after the full draw (so to 'touch' >> the first screenfull of insets) > > Sorry, I still don't understand. I also don't know very much about > how the stuff deep inside the 'LyX event loop' works. Clearly neither do I. But when we scroll, startLoading gets called for newly visible insets (probably because draw() was called for these insets?). I would want it to be called for a screenfull up and down also. > if (!running()) > startTimer(); > > is no overhead worth talking about. You are right. > I can happily concieve of a long document with graphics at the end. > Why would I need to start a timer if I'm editing at the top of the > document? Well, see above. I _do_ think it's desirable if there are graphics on the document. And if you are talking about the overhead of the timer while there is no graphics at all, I think it's negligible. > LyX used up to LyX 1.1.6. He then dissappeared. I tried to get his > code working for LyX 1.2. The result was a nasty mish mash (my fault > not Baruch's). It was also very limited. André started playing with > David Kastrup's latex-preview idea and was almost sick when he delved > into the LyX graphics code. It was very hard to extend too, so, my > embarrassment forced me to re-write it. He was very kind and > gave me lots of tips about how to 'think' clean code. > > So, call André the wizard and call me his apprentice, Mickey Mouse. Come on! So you are both wizards. > We have a nice ForkedCall class that emits a signal when the forked > process ends. We could have a function processQueue() that pops a > single item off the queue and forks a process with it. When it > finishes, the ForkedCall emits a signal which LyX uses to start the > loading process. This loading process could also call processQueue() > to pop another item off the queue. Got it, thanks. > Alternatively processQueue could write a little shell-script wrapper > of all processes in the queue and fork this 'über script'. > > The former idea, although a little more complex has the advantage > that we could load images as they become available rather than after > ALL have been converted. Indeed. Bye, Alfredo
Re: Graphics Loader
Andre Poenitz wrote: > On Wed, Feb 19, 2003 at 01:24:15PM +, Angus Leeming wrote: >> So, call André the wizard and call me his apprentice, Mickey Mouse. > > And just to give some insight into what makes a wizard in Angus' > eyes: > > One has to be too dumb to understand anything spanning more than a > screenful of code or more than three levels of any hierarchy and to > have the immodesty to call the result "good code". ...and to be convincing enough that others continue this practice. -- Angus
Re: Graphics Loader
On Wed, Feb 19, 2003 at 01:24:15PM +, Angus Leeming wrote: > So, call André the wizard and call me his apprentice, Mickey Mouse. And just to give some insight into what makes a wizard in Angus' eyes: One has to be too dumb to understand anything spanning more than a screenful of code or more than three levels of any hierarchy and to have the immodesty to call the result "good code". Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Graphics Loader
Alfredo Braunstein wrote: > Angus Leeming wrote: > >>> I see. But draw() is called for all insets at startup time, right? >> >> Yes. That's why we have to have this "see if the inset is visible" >> check (uses GraphicsSupport's isInsetVisible.) >> >> The two second pause between the call to Inset::draw and >> Loader::Impl::checkedLoading() allows the user to scroll past >> graphics insets without triggering a load unnecessarily. Only when >> the thing is visible for a finite period is loading started. > > I think this two will be obsoleted if we do it in my patch's way. > Have you tried it? No, I thought you said that you posted it for examination only? > If you scroll fast, then all insets not loaded > yet will go down the queue, replaced by newly touched ones. > And you don't need to check for visibility. I understand how it works. Nothing can be added to the queue whilst loadNext is running. However, I also disagree with your last statement above. I think it would be 'better' is loadNext itself did what checkedLoading does now; there really is no need at all to start loading/converting graphics files that aren't going to be visible. > Sorry , failed completely to explain myself. What I wanted to say > is: can we > > 1) Make avery redraw to redraw more than one screen (say 1 > fullscreen up and down) to refresh. > 2) Maybe call a redraw at startup after the full draw (so to 'touch' > the first screenfull of insets) Sorry, I still don't understand. I also don't know very much about how the stuff deep inside the 'LyX event loop' works. >> Oh yes. I see. It might be nice to have an explicit >> LoaderQueue::startLoader so that the thing is only started with the >> first attempt to 'touch' something. > > Ok, understood your previous question. I don't want to introduce > overhead in 'touch' (because it's non-threaded), but of course a > startLoader would be nice. if (!running()) startTimer(); is no overhead worth talking about. > Does this LoaderQueue belong to a bufferview? If it is so, then > I think it's not so wrong to start on the constructor. I can happily concieve of a long document with graphics at the end. Why would I need to start a timer if I'm editing at the top of the document? >> Me neither. Hence the desire for feedback. > But you have done it, big time. You _are_ a wizard. Baruch Even started writing a replacement for the graphics code that LyX used up to LyX 1.1.6. He then dissappeared. I tried to get his code working for LyX 1.2. The result was a nasty mish mash (my fault not Baruch's). It was also very limited. André started playing with David Kastrup's latex-preview idea and was almost sick when he delved into the LyX graphics code. It was very hard to extend too, so, my embarrassment forced me to re-write it. He was very kind and gave me lots of tips about how to 'think' clean code. So, call André the wizard and call me his apprentice, Mickey Mouse. >> I think that the GraphicsConverter generates a shell script wrapper >> for each conversion process. It also executes these scripts. I >> think that we could change things only slightly by getting it to >> create the scripts as it does now and putting the execute command >> on a queue to be executed sequentially. >> >> You see? You've forced me to think and the answer just 'came'. >> Thank you. > > You are welcomed! Obviously you are good at it. But without threads > (or pseudo thread) how will you execute sequentially the queue? We have a nice ForkedCall class that emits a signal when the forked process ends. We could have a function processQueue() that pops a single item off the queue and forks a process with it. When it finishes, the ForkedCall emits a signal which LyX uses to start the loading process. This loading process could also call processQueue() to pop another item off the queue. Alternatively processQueue could write a little shell-script wrapper of all processes in the queue and fork this 'über script'. The former idea, although a little more complex has the advantage that we could load images as they become available rather than after ALL have been converted. >>> Thank Angus. >>> Bye, Alfredo >> >> Tara! > What/who's Tara? Slang for 'good bye'. Pronounced ta rah. No idea where it comes from. -- Angus
Re: Graphics Loader
Angus Leeming wrote: >> I see. But draw() is called for all insets at startup time, right? > > Yes. That's why we have to have this "see if the inset is visible" > check (uses GraphicsSupport's isInsetVisible.) > > The two second pause between the call to Inset::draw and > Loader::Impl::checkedLoading() allows the user to scroll past > graphics insets without triggering a load unnecessarily. Only when > the thing is visible for a finite period is loading started. I think this two will be obsoleted if we do it in my patch's way. Have you tried it? If you scroll fast, then all insets not loaded yet will go down the queue, replaced by newly touched ones. And you don't need to check for visibility. I think the code becomes a little less convoluted indeed. >> All the document is drawn at startup, even if it's not visible. >> I'm asking this because I think the optimum would be to 'refresh' >> i.e. touch() all WaitingToLoad grafics near the cursor (up and down) >> at every time. Or something like that. > > That's essentially what we do now, although your terminology is a > little different. > Sorry , failed completely to explain myself. What I wanted to say is: can we 1) Make avery redraw to redraw more than one screen (say 1 fullscreen up and down) to refresh. 2) Maybe call a redraw at startup after the full draw (so to 'touch' the first screenfull of insets) > Oh yes. I see. It might be nice to have an explicit > LoaderQueue::startLoader so that the thing is only started with the > first attempt to 'touch' something. Ok, understood your previous question. I don't want to introduce overhead in 'touch' (because it's non-threaded), but of course a startLoader would be nice. Does this LoaderQueue belong to a bufferview? If it is so, then I think it's not so wrong to start on the constructor. > Me neither. Hence the desire for feedback. But you have done it, big time. You _are_ a wizard. > I think that the GraphicsConverter generates a shell script wrapper > for each conversion process. It also executes these scripts. I think > that we could change things only slightly by getting it to create the > scripts as it does now and putting the execute command on a queue to > be executed sequentially. > > You see? You've forced me to think and the answer just 'came'. Thank > you. You are welcomed! Obviously you are good at it. But without threads (or pseudo thread) how will you execute sequentially the queue? > >> Thank Angus. >> Bye, Alfredo > > Tara! > What/who's Tara? Thanks again, Alfredo
Re: Graphics Loader
Alfredo Braunstein wrote: >> In all cases the loading of the image is triggered by the Inset's >> draw() method. Eg InsetGraphics::draw has >>if (cache_->loader.status() == grfx::WaitingToLoad) >> cache_->loader.startLoading(*this, *bv); > > I see. But draw() is called for all insets at startup time, right? Yes. That's why we have to have this "see if the inset is visible" check (uses GraphicsSupport's isInsetVisible.) The two second pause between the call to Inset::draw and Loader::Impl::checkedLoading() allows the user to scroll past graphics insets without triggering a load unnecessarily. Only when the thing is visible for a finite period is loading started. > All the document is drawn at startup, even if it's not visible. > I'm asking this because I think the optimum would be to 'refresh' > i.e. touch() all WaitingToLoad grafics near the cursor (up and down) > at every time. Or something like that. That's essentially what we do now, although your terminology is a little different. >> Where/who would call loadNext? > loadNext is the threaded part, it's called automatically every .1 > seconds. Oh yes. I see. It might be nice to have an explicit LoaderQueue::startLoader so that the thing is only started with the first attempt to 'touch' something. >> Did you find the graphics code understandable or did you find it to >> be a convoluted mess? What could be done to improve the >> architecture? > > I think it's nice. Of course it's not simple, but neither it's task > is. I still have some problems understanding some parts. I will get > to specific questions soon. You are asking _me_ hoy to improve it? > I'm blushing again. Never programmed a graphics loading mechanism > before. Me neither. Hence the desire for feedback. >> I have a question/suggestion for you myself. (Thinking out loud >> really.) Do you think it would be easy to split the "conversion to >> loadable format" stuff out of grfx::CacheItem? >> >> At the moment we have one conversion process for each file to >> convert, so several processes run in parallel (with possibly nasty >> consequences on the system resources). It would be nice to gather >> them together into a single script and launch that. What do you >> think? >> > I think it can be easily implemented with the 'threaded' paradigm as > the image loading (even maybe together?). That's it: you request > some conversion, it is added to some queue, and done when time > comes, sequentially (by the threaded part). What do you think? I think that the GraphicsConverter generates a shell script wrapper for each conversion process. It also executes these scripts. I think that we could change things only slightly by getting it to create the scripts as it does now and putting the execute command on a queue to be executed sequentially. You see? You've forced me to think and the answer just 'came'. Thank you. > Thank Angus. > Bye, Alfredo Tara! -- Angus
Re: Graphics Loader
Angus Leeming wrote: Hi Angus, thanks for the answers. > I can answer that. Three classes are interested in graphics. > insets/insetgraphics.C together with mathed/formula.C and > insets/insetinclude.C for the previews. These latter two have > instances of a class PreviewImpl that derives from > grfx::PreviewedInset. InsetGraphics has an instance of a Cache class. > > In all cases the loading of the image is triggered by the Inset's > draw() method. Eg InsetGraphics::draw has >if (cache_->loader.status() == grfx::WaitingToLoad) > cache_->loader.startLoading(*this, *bv); I see. But draw() is called for all insets at startup time, right? All the document is drawn at startup, even if it's not visible. I'm asking this because I think the optimum would be to 'refresh' i.e. touch() all WaitingToLoad grafics near the cursor (up and down) at every time. Or something like that. > We're always nice ;-) Seriously, this is very clever of you and Im blushing. > surprisingly non-invasive. Where/who would call loadNext? loadNext is the threaded part, it's called automatically every .1 seconds. > Did you find the graphics code understandable or did you find it to > be a convoluted mess? What could be done to improve the architecture? I think it's nice. Of course it's not simple, but neither it's task is. I still have some problems understanding some parts. I will get to specific questions soon. You are asking _me_ hoy to improve it? I'm blushing again. Never programmed a graphics loading mechanism before. Let me get used to it, and I will tell you. What are the problems in it, apart from the 'convoluted' code? (I think part of the convolution will go if we make it threaded... this 2 secs call back for instance) > I have a question/suggestion for you myself. (Thinking out loud > really.) Do you think it would be easy to split the "conversion to > loadable format" stuff out of grfx::CacheItem? > > At the moment we have one conversion process for each file to > convert, so several processes run in parallel (with possibly nasty > consequences on the system resources). It would be nice to gather > them together into a single script and launch that. What do you think? > I think it can be easily implemented with the 'threaded' paradigm as the image loading (even maybe together?). That's it: you request some conversion, it is added to some queue, and done when time comes, sequentially (by the threaded part). What do you think? Thank Angus. Bye, Alfredo
Re: Graphics Loader
Alfredo Braunstein wrote: > I'm fiddling a little with the graphics loader, and I started to > implement a pseudo threaded version of it (patch attached). > > It works as follows: there is this LoaderQueue class (I think every > BufferView should have one, right now is simply a global class), > which implements a queue with a twist: > > 1) Elements are unique > 2) Reinserting an element reprioritizes it to the top > > I.e. it sort of works like the 'touch' command. > > Right now it's implemented as a queue + a set, so it's O(ln n) for > the 'first time insert' case, and O(n) for the 'already have it' > case. I plan to make it O(ln n) always. > > His loadNext method should run in an independent thread, right now > it runs with a timer that comes back every .1 seconds. I've put a > minimal locking mecanism. Should be trivial to convert to a real > thread once boost.threads is installed on the LyX tree. > > This LoaderQueue is called from Loader::startLoading, i.e. from > there we 'touch' the graphic. Nothing is really loaded on screen > yet. The real loading is done on the loadNext method (the 'threaded' > one). > > It works pretty nicely I think (except for the O(n) thingie and some > other details). And the patch is very minimal. > > I know that the coding style is broken, please correct me without > mercy. Anyway of course it's not to be applied, It's only a proof of > concept. > > I have some questions about when these Loadings are called, so if > someone thinks that this is not a complete trash then I go on and > ask them. I can answer that. Three classes are interested in graphics. insets/insetgraphics.C together with mathed/formula.C and insets/insetinclude.C for the previews. These latter two have instances of a class PreviewImpl that derives from grfx::PreviewedInset. InsetGraphics has an instance of a Cache class. In all cases the loading of the image is triggered by the Inset's draw() method. Eg InsetGraphics::draw has if (cache_->loader.status() == grfx::WaitingToLoad) cache_->loader.startLoading(*this, *bv); > Please be nice. We're always nice ;-) Seriously, this is very clever of you and surprisingly non-invasive. Where/who would call loadNext? Did you find the graphics code understandable or did you find it to be a convoluted mess? What could be done to improve the architecture? I have a question/suggestion for you myself. (Thinking out loud really.) Do you think it would be easy to split the "conversion to loadable format" stuff out of grfx::CacheItem? At the moment we have one conversion process for each file to convert, so several processes run in parallel (with possibly nasty consequences on the system resources). It would be nice to gather them together into a single script and launch that. What do you think? -- Angus
Re: Graphics Loader
Andre Poenitz wrote: > On Wed, Feb 19, 2003 at 09:43:09AM +0100, Alfredo Braunstein wrote: >> Right now it's implemented as a queue + a set, so it's O(ln n) for the >> 'first time insert' case, and O(n) for the 'already have it' case. >> I plan to make it O(ln n) always. > > Good idea, but we do pretty expensive things in othe places, so I don't > think this hurts. I think it does now, because all graphics all added to the queue at startup time, so you get a short freeze while they are at it (specially with previews). Another option would be to make the adding part also threaded. That's it: on touch() to add it to some tmp queue (without checkin) and return inmediately, and then on loadNext() load this tmp queue into the good one before proceding. > >> I know that the coding style is broken, please correct me without mercy. >> [...] Please be nice. I known. It's called sado-masochim. Thanks for the corrections. > I have not checked for functionality, I cannot connect to cvs right now, > but it does not look bad. > > Andre' > Thanks, Alfredo
Re: Graphics Loader
On Wed, Feb 19, 2003 at 09:43:09AM +0100, Alfredo Braunstein wrote:
> Right now it's implemented as a queue + a set, so it's O(ln n) for the
> 'first time insert' case, and O(n) for the 'already have it' case.
> I plan to make it O(ln n) always.
Good idea, but we do pretty expensive things in othe places, so I don't
think this hurts.
> I know that the coding style is broken, please correct me without mercy.
> [...] Please be nice.
Hm?
+class LoaderQueue {
+public:
+ LoaderQueue():timer( 100 , Timeout::ONETIME )
+ {
+ timer.timeout.connect( boost::bind( &LoaderQueue::loadNext,
this));
+ locked = false;
+ timer.start();
+ }
LoaderQueue() : timer(100, Timeout::ONETIME), locked(false)
{
timer.timeout.connect(boost::bind(&LoaderQueue::loadNext, this));
timer.start();
}
+ void touch(Cache::ItemPtr item) {
+
+ if(locked)
if (locked)
[etc]
+ timer.start();
+ };
+} LQ;
};
LoaderQueue LQ;
@@ -266,7 +313,6 @@
signal_();
}
-
void Loader::Impl::createPixmap()
Two empty lines are pretty common in LyX sources.
iff -u -r1.11 PreviewImage.C
--- PreviewImage.C 2003/02/13 16:53:00 1.11
+++ PreviewImage.C 2003/02/19 08:11:58
@@ -33,7 +33,6 @@
Image const * image(Inset const &, BufferView const &);
///
void statusChanged();
-
///
PreviewImage const & parent_;
///
As is separating member functions from member variables or blocks of them.
I have not checked for functionality, I cannot connect to cvs right now,
but it does not look bad.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: Graphics dialog
On Mon, Oct 28, 2002 at 06:24:52PM +0900, Rob Lahaye wrote: > Dekel Tsur wrote: > >No. There are only \textheight and \pageheight. > > > > We then would get: > > labeltext widthheight > > text%\textwidth \textheight > page%\pagewidth \pageheight > col% \columnwidth\columnwidth(?) > line%\linewidth \linewidth(?) > > Although that would then make sense, but it's not very consistent! Other options are: 1) Not have col% & line% options for height. or 2) Add textheight% & pageheight% options for both width & height.
Re: Re: Graphics (en) = Grafik (dt)
For me it is o. k. -- Regards, Hartmut Hungerhilfe: http://www.thehungersite.com ATTAC - für eine solidarische weltwirtschaft gegen neoliberale globalisierung: http://www.attac-netzwerk.de Mitmachen bei der GATS-Kampagne: http://www.attac-netzwerk.de/gats/ www (o o) +---oOO--(_)--OOo---+ |globalisierung ist imperialismus! | +-+ Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr! Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13
Re: Re: Graphics (en) = Grafik (dt)
For me it is o. k. -- Regards, Hartmut Hungerhilfe: http://www.thehungersite.com ATTAC - für eine solidarische weltwirtschaft gegen neoliberale globalisierung: http://www.attac-netzwerk.de Mitmachen bei der GATS-Kampagne: http://www.attac-netzwerk.de/gats/ www (o o) +---oOO--(_)--OOo---+ |globalisierung ist imperialismus! | +-+ __ Verleihen Sie Ihren E-Mails eine persönliche Note mit WEB.DE FreeMail http://freemail.web.de/features/?mc=021139
Re: Graphics (en) = Grafik (dt)
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes: Michael> Hi, I have made a few corrections/improvements to the "de.po" Michael> file. The problem is that currently the English words Michael> "Graphics" and "Figure" are both mapped onto the German word Michael> "Abbildung" which causes some confusion. I think this Michael> translation has historical reasons, so I resolved it. I'll apply that as soon as Pit or Hartmut give me a "go!". JMarc
Re: Graphics dialog
Dekel Tsur wrote: On Mon, Oct 28, 2002 at 02:28:20PM +0900, Rob Lahaye wrote: If it complicates the code, it is OK to allow selecting both \textwidth and \textheight for either the figure width or height. I'm not a LaTeX guru; does every \foowidth have a corresponding \fooheight ? (with foo is one of text, page, column, line) No. There are only \textheight and \pageheight. We then would get: labeltext widthheight text%\textwidth \textheight page%\pagewidth \pageheight col% \columnwidth\columnwidth(?) line%\linewidth \linewidth(?) Although that would then make sense, but it's not very consistent! Rob.
