mactextoolbox-talk Mailing List for Mac TeX Toolbox (Page 2)
Status: Planning
Brought to you by:
jlaurens
Menu
▾
▴
mactextoolbox-talk — Discussion for Macintosh developers for TeX Tools
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(23) |
Jul
(81) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Maxwell, A. R <ada...@pn...> - 2005-07-12 15:50:48
|
On Jul 12, 2005, at 00:45, Jan Hegewald wrote: > Hello, > do you know of any LaTeX et al. related projects regarding Spotlight? > I only know of the DVI importer by Adam Maxwell at > http://homepage.mac.com/amaxwell/ The next version of BibDesk will ship with an MDImporter, also, which =20= will have behavior similar to that of Address Book or Mail...but only =20= if you use BibDesk. > I am thinking about writing one for LaTeX or at least Plain text =20 > for files that aren=B4t indexed by default. (e.g. because mdimport =20 > says: type 'public.data' no mdimporter). But mayba there is already =20= > something like this out there? Norm Gall wrote one for his emacs distro <http://yaced.sf.net/>. No =20 idea if it works or not; I don't like installing stuff from .pkgs :). Ideally, I think each program should bundle its own MDImporter, using =20= that program's UTI, even if the importer has identical code. For =20 instance, iTeXMac and TeXniscope could each bundle a DVI importer, =20 since each can claim that UTI; however, only the program that owns =20 DVI on your system would import it (at least, I think that's how it's =20= supposed to work). My DVI importer is available under a BSD license, =20= if anyone's interested. Adam= |
|
From: Simon S. <si...@si...> - 2005-07-12 14:58:13
|
Hi, I just stumbled on Richard Cameron's CiteULike project which tries to =20= some kind of iTunes-like paper managment in combination with =20 citeUlike.org. I couldn't really figure out what's actually already =20 here, but it certainly looks interesting: http://dbk.ch.umist.ac.uk/=20 wiki/index.php?title=3DCiteULike I checked citeULike out today for the first ime and I really like it. =20= Some kind of integration with BD2 (although I don't really know how) =20 would be extremely cool. Anotther project I already posted once which could be interesting is =20 the bibconvert project which allows you to do online conversions =20 between bibtex, Endnote XML and HTML directly on their website: =20 http://dret.net/bibconvert/ simon -- Simon Spiegel Mutschellenstr. 97 8038 Z=FCrich Telephon: ++41 43 535 81 71 Mobophon: ++41 76 459 60 39 http://www.simifilm.ch "I have never been certain that the moral of the Icarus myth is, as =20 is generally accepted, 'don't fly too high', or whether it might also =20= be thought of as: 'forget about the wax and feathers, and do a better =20= job on the wings." Stanley Kubrick |
|
From: Jan H. <j.h...@tu...> - 2005-07-12 07:45:14
|
Hello, do you know of any LaTeX et al. related projects regarding Spotlight? I only know of the DVI importer by Adam Maxwell at http://homepage.mac.com/amaxwell/ I am thinking about writing one for LaTeX or at least Plain text for =20 files that aren=B4t indexed by default. (e.g. because mdimport says: =20 type 'public.data' no mdimporter). But mayba there is already =20 something like this out there? Regards, --Jan-- |
|
From: Michael M. <mic...@gm...> - 2005-07-11 19:44:29
|
As a note, there was some discussion of Cloister on the bibdesk-users mailing list a while back, you can see it starting here: http://sourceforge.net/mailarchive/forum.php?thread_id=3D6568161&forum_id= =3D11760 -mike On 7/11/05, Maarten Sneep <maa...@xs...> wrote: > Hi, >=20 > Following Massimiliano's example, I browsed the Sourceforge projects > for projects that might be interesting. I did find some: >=20 > http://sourceforge.net/projects/cloister/ - A BibDesk alternative, it > stores the bibliographic information and the PDF-files in a SQLite > database. Nowadays one would start with CoreData, but there is > certainly some overlap. >=20 > http://sourceforge.net/projects/applemods/ - An AppleScript library. >=20 > http://generateit.sourceforge.net/ - An UML tool, might be practical > for designing and refactoring of applications. >=20 > http://sourceforge.net/projects/patternbuilder/ - similar to the above. >=20 > Maarten >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar happen= ing > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual > core and dual graphics technology at this free one hour event hosted by H= P, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > -- > Mactextoolbox-talk mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/mactextoolbox-talk >=20 --=20 Michael McCracken UCSD CSE PhD Student San Diego Supercomputer Center http://www.cse.ucsd.edu/~mmccrack/ |
|
From: Maarten S. <maa...@xs...> - 2005-07-11 19:17:04
|
Hi, Following Massimiliano's example, I browsed the Sourceforge projects for projects that might be interesting. I did find some: http://sourceforge.net/projects/cloister/ - A BibDesk alternative, it stores the bibliographic information and the PDF-files in a SQLite database. Nowadays one would start with CoreData, but there is certainly some overlap. http://sourceforge.net/projects/applemods/ - An AppleScript library. http://generateit.sourceforge.net/ - An UML tool, might be practical for designing and refactoring of applications. http://sourceforge.net/projects/patternbuilder/ - similar to the above. Maarten |
|
From: <jer...@u-...> - 2005-07-11 12:24:16
|
Le 11 juil. 05, =E0 12:21, Massimiliano Gubinelli a =E9crit : > Hi, > I've just discovered the IDEKit framework=20 > (http://projects.gandreas.com/idekit/). It contains various classes=20 > for building IDE (a la Xcode): text editor with syntax highlight,=20 > uniquing of files and a kind of metadata support (like managing=20 > breakpoints for debugging), projects, key bindings editor, console,=20 > etc. Seems nice and not badly written. > Does anybody else have experience with it? How does it compare with=20 > the setup Jerome has wrote for iTeXMac2? > I took a look at it and found it valuable. I wondered if I should start iTM2 from this but after some analysis, I=20= came to the conclusion that syntax coloring, macro management and key=20 bindings management I already had in iTM was superior to the ones in=20 IDEKit. Moreover, the file management and metadata storage had to be=20 seriously revisited to be really portable. AFAIR, I liked very much the=20= preference management of IDEKit and will probably use it. Finally, I found some design choices very constraining. More precisely,=20= I really like the "one document -> many window controllers" approach=20 available in the AppKit, and this is killed by IDEKit. |
|
From: Massimiliano G. <mg...@ma...> - 2005-07-11 10:22:14
|
Hi, I've just discovered the IDEKit framework (http:// projects.gandreas.com/idekit/). It contains various classes for building IDE (a la Xcode): text editor with syntax highlight, uniquing of files and a kind of metadata support (like managing breakpoints for debugging), projects, key bindings editor, console, etc. Seems nice and not badly written. Does anybody else have experience with it? How does it compare with the setup Jerome has wrote for iTeXMac2? ciao, Massimiliano Gubinelli |
|
From: <jer...@u-...> - 2005-07-08 10:23:58
|
Le 6 juil. 05, =E0 23:15, Maarten Sneep a =E9crit : > On 6 Jul 2005, at 8:38, J=E9r=F4me Laurens wrote: > >> Le 5 juil. 05, =E0 22:39, Maarten Sneep a =E9crit : >> >>> Why would you want to change the name of the master file? I don't=20 >>> get the example you give here - since the slave-files are stored in=20= >>> the master file, and their relative location is fixed through the=20 >>> \input statement (or format specific alternatives). So _moving_ the=20= >>> master is not an option, and renaming (IMHO) is a relatively rare=20 >>> action. Inefficiency is unimportant for such cases. >>> >> >> Gerben just gave me an example where he splitted a big book in=20 >> several chapters, each one could be typeset separately. >> Changing the master name allows this. If each chapter consists of one=20= >> file, you just change the master file name in the header, but if it=20= >> consists of many different files, then this is not practical. > > Call me thick-headed, but I don't see how this works. Care to share a=20= > minimal example? I do not use this design myself but I trust Gerben when he tells me he=20= does (especially when ConTeXt is involved) For latex, I think that many different copies of the master files with=20= different \includeonly declarations will do the job. It is easy to ensure that the preamble is the same except the=20 includeonly's.= |
|
From: Maxwell, A. R <ada...@pn...> - 2005-07-06 21:31:23
|
On Jul 6, 2005, at 13:42, Maarten Sneep wrote: > On 5 Jul 2005, at 23:33, Maxwell, Adam R wrote: > > >> I think XeTeX accepts either UTF-16 or UTF-8. >> > > I doubt it, I think it only eats UTF-8. Besides, UTF-16 is very > recognisable when read as a sequence of bytes (a lot of zero's are > interspersed in the sequence). Doubt no longer: <http://www.tug.org/pipermail/xetex/2004-October/ 001153.html>. >> Also, trying to read Latin 1 files in as UTF-8 will cause an error >> in Cocoa, and you get nothing back >> > > Well, read it as a sequence of unsigned bytes, discard all values > > 127, and start searching for the marker that indicates the > encoding. If you encounter a lot of zero's, you probably have > UTF-16. Once you've found the real encoding, close the file, and re- > open with the now known encoding. I interpreted your earlier suggestion as "read all files as UTF-8," so I was just trying to point out that this will not work in all cases. Sniffing bytes to interpret a comment is probably possible, although messy, but reading the encoding from a comment will still only work if the information is up to date (i.e. machine-written when saving). For that, I think you'll need some comment block that says "Don't edit this," since users are notorious for unknowingly changing encodings. Adam |
|
From: Maarten S. <maa...@xs...> - 2005-07-06 21:20:39
|
On 6 Jul 2005, at 15:19, Adam R. Maxwell wrote: > On Jul 6, 2005, at 04:41, J=E9r=F4me Laurens wrote: [on aliases] >> This is not a portable solution. Aliases are mac specific. >> A solution viable on other systems must also be considered > > Personally, I don't care about other systems, but if they must be =20 > considered for the mactextoolbox, why not add another piece of =20 > metadata? Store a path and an alias in the plist. I do care about other systems. I didn't get a Mac with my new job, I =20 my daily work now takes place on a Linux machine. Besides, even when =20 on a Mac alone, many non-mac specific pieces may touch the files =20 (CVS, subversion) that might break aliases. But indeed, a double =20 storage is fine. [on character encodings] >> Or an ascii name? > > If you can write into the byte stream without corrupting it... I thought that initially we are only trying to retrieve the character =20= encoding, and reading a byte stream doesn't do any harm. Once you =20 figure out the encoding, you can really manipulate the stream. Maarten |
|
From: Maarten S. <maa...@xs...> - 2005-07-06 21:16:02
|
On 6 Jul 2005, at 8:38, J=E9r=F4me Laurens wrote: > Le 5 juil. 05, =E0 22:39, Maarten Sneep a =E9crit : > >> Why would you want to change the name of the master file? I don't =20 >> get the example you give here - since the slave-files are stored =20 >> in the master file, and their relative location is fixed through =20 >> the \input statement (or format specific alternatives). So =20 >> _moving_ the master is not an option, and renaming (IMHO) is a =20 >> relatively rare action. Inefficiency is unimportant for such cases. >> > > Gerben just gave me an example where he splitted a big book in =20 > several chapters, each one could be typeset separately. > Changing the master name allows this. If each chapter consists of =20 > one file, you just change the master file name in the header, but =20 > if it consists of many different files, then this is not practical. Call me thick-headed, but I don't see how this works. Care to share a =20= minimal example? > Assuming that master files are property identified (with the name, =20 > \documentclass, inline comment), slave files are the ones below. I can understand the master -> slave direction, after all TeX needs =20 that information to typeset the file. However, if I open a random =20 slave file, how is a front-end going to find the master? Or am I =20 misreading this statement, and do you mean that the slave-file should =20= contain some information on its master (the documentclass, the master =20= file, ...). > In the TeX Wrapper Structure I presented in EuroTeX 2005, there are =20= > dedicated room for frontend specific and user specific metadata. > For frontend specific metadata, it's just a naming convention to =20 > avoid collisions, such that quite nothing needs to be changed for =20 > actual editors. OK, that would work, although you might need a machine or screen-size =20= dependent category to prevent the window-size clashes I mentioned. >> With the marks I agree, with the collapsing region bounds, I'm not =20= >> too sure: they may be a personal preference, not shared between =20 >> collaborators. This information can be stored outside the source =20 >> file (in some project file, which can contain the lot in a TeX =20 >> wrapper - however they may look*). > > marks are also personnal, they can just be used as stickies. But the marks can also serve as pointers to co-editors, to point them =20= to changes you've made, or important remaining issues. I think most =20 users who share their file will want the markers to be shared (I know =20= I do). However, with collapsing sections, I'm not so sure. >> The description of where the different points are inserted - if =20 >> _all_ metadata is expelled from the source files to some external =20 >> storage - may very well need to change, from a line-count to a =20 >> node count. >> > > Exactly, different locations for the metadata serve different =20 > purposes and we definitely need both. And sometimes as a back-up of the other, possibly less robust =20 location. I still need to do some testing on CVS maintained files as =20 a target for aliases, extended attributes on files, and some more =20 robustness checks. >> loc description >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> 1,2 text encoding (extended attribute, in-file, project file) >> 1 markers (in file - easiest, most robust) >> 3 window location (private use only) >> 1,2 master file (extended attribute, in-file, project file) >> . . . >> > > Agreed except for 3. but still preferred in a location that is not shared between users or =20= even machines: the 12", 30" mismatch was mentioned before. > All these are recommandations, and the frontends will do what they =20 > prefer. > But my opinion is the following: > If a frontend wants to implement something, he can do whatever he =20 > wants, but there might be dedicated locations for that. > Every metadata can be stored in either 1, 2 and 3. > > For the window location, we can state that: > if the front end wants to store it in its private domain, he can do =20= > whatever he wants. > If the front end wants to store it near the file it refers to, then =20= > there is some place already reserved for this, and it should use it. > The frontend is not encouradge to embed this kind of information in =20= > the file. That is for sure, in my opinion, there are only a few items critical =20 enough to warrant storage inside the file as an emergency backup: the =20= character encoding and the master file. I think that the markers =20 belong inside the file - it feels very natural to me - and they can =20 then be used easily with other editors that support regular =20 expressions for markers (BBEdit, perhaps others). Is anyone prepared to create a summary of this thread to later =20 reference? Maarten= |
|
From: Maarten S. <maa...@xs...> - 2005-07-06 20:42:13
|
On 5 Jul 2005, at 23:33, Maxwell, Adam R wrote: > I think XeTeX accepts either UTF-16 or UTF-8. I doubt it, I think it only eats UTF-8. Besides, UTF-16 is very =20 recognisable when read as a sequence of bytes (a lot of zero's are =20 interspersed in the sequence). > Also, trying to read Latin 1 files in as UTF-8 will cause an error =20 > in Cocoa, and you get nothing back Well, read it as a sequence of unsigned bytes, discard all values > =20 127, and start searching for the marker that indicates the encoding. =20 If you encounter a lot of zero's, you probably have UTF-16. Once =20 you've found the real encoding, close the file, and re-open with the =20 now known encoding. > (although this is arguably better than the corruption you get when =20 > reading MacOSRoman as UTF-8 or something). Again, just open the file after you've figured out the real encoding. For reference, I looked up how XML solves the problem. After all, =20 they store the encoding information in the file as well. For =20 reference I used XML in a Nutshell, third edition, by Harold and =20 Means, published by O'Reilly. It says: ... Many web servers omit the charset parameter from the MIME media =20 type. In this case, if the MIME media type is text/xml, then the =20 document is assumed to be in the US-ASCII encoding. If the MIME type =20 is application/xml, then the parser attempts to guess the character =20 set by reading the first few bytes of the document. (explanation of why they consider MIME types in the first place =20 omitted. However, guesswork seems to be part of the standard. Ouch.). Every XML document should have an encoding declaration as part of its =20= XML declaration. The encoding declaration tells the parser in which =20 character set the document is written. It's used only when other =20 metadata from outside the file is not available. For example, this =20 XML declaration says that the document uses the Latin-1 character =20 set, with the official name ISO-8859-1: <?xml version=3D"1.0" encoding=3D"ISO-8859-1"?> (end quote) I think we could do worse than adapt a similar strategy. However, =20 since TeX itself has no direct way of specifying processing =20 instructions, this backup metadata should be encoded in a comment. =20 The xml declaration starts right at the start of the document. Since =20 all 8-bit encodings share the lower 7 bits with US-ASCII, and UTF-8 =20 does so as well, this method actually works for figuring out the real =20= encoding. [massive snip] > XeTeX might be an exception to this, as previously noted, so =20 > storing encoding in the file might be practi=13ca=13ble for a shorter = =20 > time than we realize. I don't think you'll have trouble recognising UTF-16 from the file =20 itself. And for the other 8-bit encodings it is possible to extract =20 the encoding by starting from US-ASCII. Maarten= |
|
From: Maxwell, A. R <ada...@pn...> - 2005-07-06 18:21:41
|
On Jul 6, 2005, at 10:45, J=E9r=F4me Laurens wrote: > > Le 6 juil. 05, =E0 17:54, Maxwell, Adam R a =E9crit : > > >> >> On Jul 6, 2005, at 08:16, Jon Guyer wrote: >> >> >>> >>> On Jul 6, 2005, at 10:18 AM, J=E9r=F4me Laurens wrote: >>> >>> >>> >>>> What will happen if I duplicate a file, for example by copying =20 >>>> it on a USB memory key, then copy it on my home computer, then =20 >>>> copy it back. What is the location pointed to by the alias? It =20 >>>> might be consistent but not correct. >>>> This is an example where the path can be correct but the alias =20 >>>> can be broken. >>>> On the other hand, changing a file name will break the stored =20 >>>> path but not the alias. >>>> >>>> >>> >>> Aliases can be relative <http://developer.apple.com/samplecode/=20 >>> resolveRelativeAlias/resolveRelativeAlias.html> >>> >> >> Or if you don't grok Pascal (or whatever that sample is :)... >> >> <http://developer.apple.com/documentation/MacOSX/Conceptual/=20 >> BPFileSystem/Concepts/Aliases.html> has some info on relative =20 >> paths vs. aliases. >> >> If you're using Cocoa, BDAlias is useful for working with aliases =20 >> and paths, especially for serializing aliases: <http://=20 >> bdistributed.com/Projects/BDAlias/>. >> >> My own view is that hard-coded paths in plists and code are evil, =20 >> whether they are paths to a recent file, Application Support, =20 >> Preferences, or a temp directory. >> >> -- Adam >> >> >> > > could not get this to work: > > create a new cocoa application project, add BDAlias, and use the =20 > following main > [...] > > > In the nib, subclass the NSApplication to add a =20 > createRelativeAlias: message, and a textField outlet. > Make the owner an instance of this class. Or create a Cocoa application and add a controller object as NSApp =20 delegate, which is what I just did. > > Run the app. The alias created does not take into account the =20 > NSHomeDirectory()/Documents as absolute reference. > > Things are complicated. I think this is expected behavior. If you check the docs for =20 FSResolveAlias, the relativePath part is just a starting place for =20 finding the path to the FSRef. Did it not return the correct full path? If you want a relative path in Unix terms, things get pretty =20 complicated, although stringByAbbreviatingWithTildeInPath usually =20 (but not always) works to give you a home directory-relative path. Adam= |
|
From: Jon G. <jg...@hi...> - 2005-07-06 18:03:46
|
On Jul 6, 2005, at 1:46 PM, Maxwell, Adam R wrote: > I just figured you were one of those Carbon geezers who still uses > ResEdit :). Guilty as charged. ;^) |
|
From: <jer...@u-...> - 2005-07-06 17:47:38
|
Le 6 juil. 05, =E0 17:54, Maxwell, Adam R a =E9crit : > > On Jul 6, 2005, at 08:16, Jon Guyer wrote: > >> >> On Jul 6, 2005, at 10:18 AM, J=E9r=F4me Laurens wrote: >> >> >>> What will happen if I duplicate a file, for example by copying it on = =20 >>> a USB memory key, then copy it on my home computer, then copy it =20 >>> back. What is the location pointed to by the alias? It might be =20 >>> consistent but not correct. >>> This is an example where the path can be correct but the alias can =20= >>> be broken. >>> On the other hand, changing a file name will break the stored path =20= >>> but not the alias. >>> >> >> Aliases can be relative =20 >> <http://developer.apple.com/samplecode/resolveRelativeAlias/=20 >> resolveRelativeAlias.html> > > Or if you don't grok Pascal (or whatever that sample is :)... > > <http://developer.apple.com/documentation/MacOSX/Conceptual/=20 > BPFileSystem/Concepts/Aliases.html> has some info on relative paths =20= > vs. aliases. > > If you're using Cocoa, BDAlias is useful for working with aliases and =20= > paths, especially for serializing aliases: =20 > <http://bdistributed.com/Projects/BDAlias/>. > > My own view is that hard-coded paths in plists and code are evil, =20 > whether they are paths to a recent file, Application Support, =20 > Preferences, or a temp directory. > > -- Adam > > could not get this to work: create a new cocoa application project, add BDAlias, and use the =20 following main int main(int argc, char *argv[]) { return NSApplicationMain(argc, argv); } #import "BDAlias.h" static id textField; @implementation NSApplication(h) - (void) setTextField: (id) sender; { textField =3D sender; } - (IBAction) createRelativeAlias: (id) sender; { NSOpenPanel * OP =3D [NSOpenPanel openPanel]; [OP setAllowsMultipleSelection:NO]; [OP setCanChooseDirectories: NO]; if ([OP runModalForTypes:nil] =3D=3D NSOKButton) { NSString *target =3D [[OP filenames] lastObject]; BDAlias * alias =3D [BDAlias aliasWithPath: [target =20 lastPathComponent] relativeToPath: [target =20 stringByDeletingLastPathComponent]]; [textField setStringValue: [alias fullPathRelativeToPath: =20 NSHomeDirectory()]]; } } @end In the nib, subclass the NSApplication to add a createRelativeAlias: =20 message, and a textField outlet. Make the owner an instance of this class. Run the app. The alias created does not take into account the =20 NSHomeDirectory()/Documents as absolute reference. Things are complicated.= |
|
From: <jer...@u-...> - 2005-07-06 17:47:16
|
Le 6 juil. 05, =E0 17:16, Jon Guyer a =E9crit : > > On Jul 6, 2005, at 10:18 AM, J=E9r=F4me Laurens wrote: > >> What will happen if I duplicate a file, for example by copying it on =20= >> a USB memory key, then copy it on my home computer, then copy it =20 >> back. What is the location pointed to by the alias? It might be =20 >> consistent but not correct. >> This is an example where the path can be correct but the alias can be = =20 >> broken. >> On the other hand, changing a file name will break the stored path =20= >> but not the alias. > > Aliases can be relative =20 > <http://developer.apple.com/samplecode/resolveRelativeAlias/=20 > resolveRelativeAlias.html> > >> This is a siuation were mac aliases are not that superior to sym =20 >> links... > > Bite your tongue! > > Not convinced, though my pascal is far away..., my tongue is still =20 intact.= |
|
From: Maxwell, A. R <ada...@pn...> - 2005-07-06 17:46:54
|
On Jul 6, 2005, at 10:36, Jon Guyer wrote: > > On Jul 6, 2005, at 11:54 AM, Maxwell, Adam R wrote: > > >>> Aliases can be relative <http://developer.apple.com/samplecode/ >>> resolveRelativeAlias/resolveRelativeAlias.html> >>> >> >> Or if you don't grok Pascal (or whatever that sample is :)... >> > > You didn't expect me to actually /read/ the link I posted, did you? I just figured you were one of those Carbon geezers who still uses ResEdit :). Adam |
|
From: Jon G. <jg...@hi...> - 2005-07-06 17:36:19
|
On Jul 6, 2005, at 11:54 AM, Maxwell, Adam R wrote: >> Aliases can be relative >> <http://developer.apple.com/samplecode/resolveRelativeAlias/ >> resolveRelativeAlias.html> > > Or if you don't grok Pascal (or whatever that sample is :)... You didn't expect me to actually /read/ the link I posted, did you? |
|
From: Maxwell, A. R <ada...@pn...> - 2005-07-06 15:55:02
|
On Jul 6, 2005, at 08:16, Jon Guyer wrote: > > On Jul 6, 2005, at 10:18 AM, J=E9r=F4me Laurens wrote: > > >> What will happen if I duplicate a file, for example by copying it =20 >> on a USB memory key, then copy it on my home computer, then copy =20 >> it back. What is the location pointed to by the alias? It might be =20= >> consistent but not correct. >> This is an example where the path can be correct but the alias can =20= >> be broken. >> On the other hand, changing a file name will break the stored path =20= >> but not the alias. >> > > Aliases can be relative <http://developer.apple.com/samplecode/=20 > resolveRelativeAlias/resolveRelativeAlias.html> Or if you don't grok Pascal (or whatever that sample is :)... <http://developer.apple.com/documentation/MacOSX/Conceptual/=20 BPFileSystem/Concepts/Aliases.html> has some info on relative paths =20 vs. aliases. If you're using Cocoa, BDAlias is useful for working with aliases and =20= paths, especially for serializing aliases: <http://bdistributed.com/=20 Projects/BDAlias/>. My own view is that hard-coded paths in plists and code are evil, =20 whether they are paths to a recent file, Application Support, =20 Preferences, or a temp directory. -- Adam |
|
From: Jon G. <jg...@hi...> - 2005-07-06 15:17:02
|
On Jul 6, 2005, at 10:18 AM, J=E9r=F4me Laurens wrote: > What will happen if I duplicate a file, for example by copying it on a = =20 > USB memory key, then copy it on my home computer, then copy it back. =20= > What is the location pointed to by the alias? It might be consistent =20= > but not correct. > This is an example where the path can be correct but the alias can be =20= > broken. > On the other hand, changing a file name will break the stored path but = =20 > not the alias. Aliases can be relative =20 <http://developer.apple.com/samplecode/resolveRelativeAlias/=20 resolveRelativeAlias.html> > This is a siuation were mac aliases are not that superior to sym =20 > links... Bite your tongue! |
|
From: Adam R. M. <ama...@ma...> - 2005-07-06 14:31:32
|
On Jul 6, 2005, at 07:18, J=E9r=F4me Laurens wrote: > > Le 6 juil. 05, =E0 15:19, someone wrote, but I've lost the quoting =20 > hierarchy > > >>>> >>>> >>>>> If you store aliases as data in a plist, though (BDAlias is =20 >>>>> handy for this), renaming isn't a problem for the front-end =20 >>>>> specific info. >>>>> >>>>> >>>> >>>> Ooo, that sounds much nicer than hard coded links at the top of =20 >>>> the document...(even if they are relative) >>>> >>>> >>> >>> This is not a portable solution. Aliases are mac specific. >>> A solution viable on other systems must also be considered >>> >> >> Personally, I don't care about other systems, but if they must be =20 >> considered for the mactextoolbox, why not add another piece of =20 >> metadata? Store a path and an alias in the plist. >> > > In fact, I did not only mean different operating systems. > > What will happen if I duplicate a file, for example by copying it =20 > on a USB memory key, then copy it on my home computer, then copy it =20= > back. What is the location pointed to by the alias? It might be =20 > consistent but not correct. > This is an example where the path can be correct but the alias can =20 > be broken. > On the other hand, changing a file name will break the stored path =20 > but not the alias. > > So a good solution might be to store both the file and the alias, =20 > use the relative path and if it appears to be corrupted, the alias. > > This is a siuation were mac aliases are not that superior to sym =20 > links... Yes, this is why you have to prefer paths to aliases if both exist (I =20= think the OS implementation of aliases does this also, after 10.2?). >>>> [...] >>>> it sounds like a "checksum" string at the end of the document =20 >>>> that is unique for each encoding (is this even possible?) is the =20= >>>> only way to do it if the information is going to be kept in-file. >>>> >>>> >>> >>> Or an ascii name? >>> >> >> If you can write into the byte stream without corrupting it... >> > > Isn't there already strong 16 bits and 32 bits BOM? > I still don't understand what really exist on that matter. BOM only tells you if you have big-endian or little-endian data: =20 <http://www.unicode.org/faq/utf_bom.html#BOM>, and they say that you =20 can use it to differentiate between the different UTF variants. I =20 think the main problem is that it isn't always present (and of course =20= it doesn't help with legacy encodings). Adam |
|
From: <jer...@u-...> - 2005-07-06 14:20:38
|
Le 6 juil. 05, =E0 15:19, someone wrote, but I've lost the quoting=20 hierarchy >>> >>>> If you store aliases as data in a plist, though (BDAlias is handy=20= >>>> for this), renaming isn't a problem for the front-end specific=20 >>>> info. >>>> >>> >>> Ooo, that sounds much nicer than hard coded links at the top of the=20= >>> document...(even if they are relative) >>> >> >> This is not a portable solution. Aliases are mac specific. >> A solution viable on other systems must also be considered > > Personally, I don't care about other systems, but if they must be=20 > considered for the mactextoolbox, why not add another piece of=20 > metadata? Store a path and an alias in the plist. In fact, I did not only mean different operating systems. What will happen if I duplicate a file, for example by copying it on a=20= USB memory key, then copy it on my home computer, then copy it back.=20 What is the location pointed to by the alias? It might be consistent=20 but not correct. This is an example where the path can be correct but the alias can be=20 broken. On the other hand, changing a file name will break the stored path but=20= not the alias. So a good solution might be to store both the file and the alias, use=20 the relative path and if it appears to be corrupted, the alias. This is a siuation were mac aliases are not that superior to sym=20 links... > >>> >>> [...] >>> it sounds like a "checksum" string at the end of the document that=20= >>> is unique for each encoding (is this even possible?) is the only way=20= >>> to do it if the information is going to be kept in-file. >>> >> >> Or an ascii name? > > If you can write into the byte stream without corrupting it... Isn't there already strong 16 bits and 32 bits BOM? I still don't understand what really exist on that matter. |
|
From: Adam R. M. <ama...@ma...> - 2005-07-06 13:19:58
|
On Jul 6, 2005, at 04:41, J=E9r=F4me Laurens wrote: > > Le 6 juil. 05, =E0 00:19, Will Robertson a =E9crit : > > >> On 6 Jul 2005, at 7:03 AM, Maxwell, Adam R wrote: >> >> >>> If you store aliases as data in a plist, though (BDAlias is handy =20= >>> for this), renaming isn't a problem for the front-end specific info. >>> >> >> Ooo, that sounds much nicer than hard coded links at the top of =20 >> the document...(even if they are relative) >> > > This is not a portable solution. Aliases are mac specific. > A solution viable on other systems must also be considered Personally, I don't care about other systems, but if they must be =20 considered for the mactextoolbox, why not add another piece of =20 metadata? Store a path and an alias in the plist. >> >> >>> I think XeTeX accepts either UTF-16 or UTF-8. Also, trying to =20 >>> read Latin 1 files in as UTF-8 will cause an error in Cocoa, and =20 >>> you get nothing back (although this is arguably better than the =20 >>> corruption you get when reading MacOSRoman as UTF-8 or something). >>> >> >> In that case, it sounds like a "checksum" string at the end of the =20= >> document that is unique for each encoding (is this even possible?) =20= >> is the only way to do it if the information is going to be kept in-=20= >> file. >> > > Or an ascii name? If you can write into the byte stream without corrupting it... Adam |
|
From: <jer...@u-...> - 2005-07-06 11:43:33
|
Le 6 juil. 05, =E0 00:19, Will Robertson a =E9crit : > On 6 Jul 2005, at 7:03 AM, Maxwell, Adam R wrote: > >> If you store aliases as data in a plist, though (BDAlias is handy for=20= >> this), renaming isn't a problem for the front-end specific info. > > Ooo, that sounds much nicer than hard coded links at the top of the=20 > document...(even if they are relative) This is not a portable solution. Aliases are mac specific. A solution viable on other systems must also be considered In the iTM2 I am implementing, nothing is put in the header... > >> Why put the name of the master file in the slaves if TeX doesn't need=20= >> it (or maybe it does...I'm not much of a TeXpert)? > > So that when you open up the chapter file you're working on that=20 > doesn't have anything but document text, you can still hit "Typeset"=20= > and have something come out :) The problem comes from multipart documents, should the whole document=20 be typeset or only the chapter (if relevant) We can think of books made with collections of disconnected articles.=20 It that case, it really makes sense to either typeset the whole=20 document or only one chapter... > >> I think XeTeX accepts either UTF-16 or UTF-8. Also, trying to read=20= >> Latin 1 files in as UTF-8 will cause an error in Cocoa, and you get=20= >> nothing back (although this is arguably better than the corruption=20 >> you get when reading MacOSRoman as UTF-8 or something). > > In that case, it sounds like a "checksum" string at the end of the=20 > document that is unique for each encoding (is this even possible?) is=20= > the only way to do it if the information is going to be kept in-file. Or an ascii name? |
|
From: <jer...@u-...> - 2005-07-06 06:40:53
|
Le 5 juil. 05, =E0 22:39, Maarten Sneep a =E9crit : > On 4 Jul 2005, at 12:23, J=E9r=F4me Laurens wrote: > >> Le 3 juil. 05, =E0 02:16, Will Robertson a =E9crit : >> >>> I honestly have no problem, for now, with implementing metadata in=20= >>> the same way as emacs: in a big comment block at the very end of the=20= >>> document. It would be easy to hide from the user, and is very=20 >>> portable. >> >> Yes, but not all metadata data should fit there. >> And this is can be closed design. > > Any design can be closed, but I have a hard time seeing an in-file=20 > comment-tag, plain to see for all, and even with documentation - if=20 > you pester an emacs adept long enough for it - as a closed design. emacs, or at leaset auctex also uses an external diretory named Auto=20 where it stores meta data. The name Auto can be changed with an iinline comment. > >> For example, if you put the master file name of a tex source file at=20= >> the end of the source file (like emacs does), it will be hard coded=20= >> in each slave file. >> When you change the master file (what we are going to need for=20 >> efficiency) you will have to change that information in each slave=20 >> file concerned... Not very efficient. > > Why would you want to change the name of the master file? I don't get=20= > the example you give here - since the slave-files are stored in the=20 > master file, and their relative location is fixed through the \input=20= > statement (or format specific alternatives). So _moving_ the master is=20= > not an option, and renaming (IMHO) is a relatively rare action.=20 > Inefficiency is unimportant for such cases. Gerben just gave me an example where he splitted a big book in several=20= chapters, each one could be typeset separately. Changing the master name allows this. If each chapter consists of one=20 file, you just change the master file name in the header, but if it=20 consists of many different files, then this is not practical. > >> So you need to embed only a reference to the location where the=20 >> master information is stored, such that the reference never changes,=20= >> but the information it points to can. That way, you just have to=20 >> change the master name in one location, and all the slave files will=20= >> be linked to that info automatically. This is some kind of aliasing.=20= >> The best policy is to put nothing in the source file. > > I don't get this: how is putting the information in another file=20 > solving something? The slave files need to reference something, or=20 > else: how are you going to pick this reference up when someone opens a=20= > random tex file - that turns out to be some slave file. Assuming that master files are property identified (with the name,=20 \documentclass, inline comment), slave files are the ones below. > >> Another big problem concerning metadata in the source deals with the=20= >> encoding. >> The encoding is meant to deal with the text only, but it will=20 >> naturally apply to the metadata too. >> People using marks would want to use utf16 because it fits their=20 >> natural language and they feel far more comfortable with that (the=20 >> same for tex comments). For more general metadata, some frontends=20 >> might want to store pure binary metadata... But if the metadata are=20= >> embedded, those things will be forbidden. > > Last time I checked there were no TeX engines that accepted utf-16.=20 > Since utf-8 is a strict superset of ASCII, I don't think there is a=20 > problem, especially since both uft versions can encode the same=20 > information. Omega, maybe some day... > > And for pure binary metadata: I ran away from word to get rid of=20 > binary files, so if a special project file needs to be added, let it=20= > be an xml file - or something else BBEdit can handle. Exactly. This is why I chose a property list for iTM. > >>> On the other hand, if there are other standards that spring up for=20= >>> storing the encoding of the file in an extended attribute -- well,=20= >>> we may as well use that as well! (too many `well's) >>> >>> I am more interested with the possibilities raised from a rich=20 >>> document interface, and I think WHERE the metadata is stored is less=20= >>> of an issue -- it can always be changed if a new method turns out to=20= >>> be better. >> >> My opinion is the following: >> >> We have 3 locations to save metadata attributes >> >> 1 - inside the source file, like emacs does >> 2 - in an external file at a definite location relative to the source=20= >> file, like resource forks and the TeX Wrapper Structure I presented=20= >> in EuroTeX 2005 >> 3 - in an external file at a definite location, relative to the=20 >> application, like BBEdit and TextWrangler do, like unix app do in=20 >> their .cshrc and alike... >> >> 3 is not portable. >> Moreover, I am wondering why BBEdit put this 15 days limit... May be=20= >> they had a structural reason that prohibits an intense use of this=20 >> design... > > About 313 entries and counting. There are some types of metadata you=20= > do not want to inherit from coworkers, while keeping them for your own=20= > sessions: window locations come to mind (especially if you have a 12"=20= > powerbook, and the colleague has a 30" display). I think you are too=20= > quick in discounting the private option for (some types) of metadata. In the TeX Wrapper Structure I presented in EuroTeX 2005, there are=20 dedicated room for frontend specific and user specific metadata. For frontend specific metadata, it's just a naming convention to avoid=20= collisions, such that quite nothing needs to be changed for actual=20 editors. > >> So only 1 and 2 remain, and no choice should be made between them:=20 >> they are different and will serve different purposes, we need both. >> >> For point 1, marks and collapsing region bounds are the only kind of=20= >> informations that really need to be stored inside the source. > > With the marks I agree, with the collapsing region bounds, I'm not too=20= > sure: they may be a personal preference, not shared between=20 > collaborators. This information can be stored outside the source file=20= > (in some project file, which can contain the lot in a TeX wrapper -=20 > however they may look*). marks are also personnal, they can just be used as stickies. > >> Moreover, in a very near future, it will not be strange to use an XML=20= >> input instead of the standard tex input. > > The engine underneath is still likely to be TeX - and for the=20 > foreseeable future that means utf-8 input, not utf-16 or utf-32, but=20= > that is a minor remark here. > It does mean that at the very least for now we can store the text=20 > encoding in the file itself, and for XML there are official options,=20= > also in-file. > >> If we want to store the same metadata in the source file, we will=20 >> have to design another mean for that purpose. > > XML files can contain comments as well, no real need to change=20 > anything here, if at least we keep this in the back of our minds.=20 > OTOH, xml may require such a different editor because of the=20 > verbosity-level, that keeping it in hte back of our minds is way too=20= > much honour. > >> If the same metadata were saved in an external location, the format=20= >> of the storage would not suffer the adoption of xml for input files,=20= >> and no extra work would be necessary. > > The description of where the different points are inserted - if _all_=20= > metadata is expelled from the source files to some external storage -=20= > may very well need to change, from a line-count to a node count. Exactly, different locations for the metadata serve different purposes=20= and we definitely need both. > >> Finally 1 -and- 2 are the only choice. Now, the problem is to define=20= >> what kind of meta information should be stored and where. > > I still think there is a place for 3, but you're right in stating that=20= > the really interesting question is what should be stored. Yes, but this is private to frontends and is not shared, so nothing to=20= discuss. > > loc description > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 1,2 text encoding (extended attribute, in-file, project file) > 1 markers (in file - easiest, most robust) > 3 window location (private use only) > 1,2 master file (extended attribute, in-file, project file) > . . . Agreed except for 3. All these are recommandations, and the frontends will do what they=20 prefer. But my opinion is the following: If a frontend wants to implement something, he can do whatever he=20 wants, but there might be dedicated locations for that. Every metadata can be stored in either 1, 2 and 3. For the window location, we can state that: if the front end wants to store it in its private domain, he can do=20 whatever he wants. If the front end wants to store it near the file it refers to, then=20 there is some place already reserved for this, and it should use it. The frontend is not encouradge to embed this kind of information in the=20= file. The=20= |
