Offline Parts Catalogue


Offline Parts Catalogue
#1
Hi all
I'm new to the program and have to say I'm loving every second I use of it.
The only issue I have really is that as a new person I'm having a bit of a mission finding the parts I want. I know there are websites with parts and bigger pictures of them but is there a Catalogue for off line use?

I mainly use the Lego cad on my laptop (big screen and lots of ram!) and normally out of 3G signal so i would find a sort of PDF parts catalogue really usefull if there is one.
Reply
Re: Offline Parts Catalogue
#2
I'm not sure if I understood you correctly.

Are you asking how and what to download?
Then your question coincides with the topic which I just have brought up:
http://forums.ldraw.org/showthread.php?t...49#pid5649

Once you have all wanted files on your harddisk
(most probably simply "all official ones"),
many of the tools allow you to browse the parts interactively.

PS
I also would appreciate a beautifully rendered
"all official parts" PDF
(i.e., not only the parts within an incremental update,
but the entirety of our library)
- simply for browsing fun. I love looking at all our parts...
Reply
Re: Offline Parts Catalogue
#3
I get this request quite often and would love to add such a cataloge to the AIOI. I could render thumbnails of the parts folder's content by running a LDView batch file but this is just half the job.

* Ideal would be a script which generates PDF pages with a header (Image/Number/Description)
* Comes with a search string feature. Something down the line of the search feature in MLCad, with <Brick, Plate>, <Minifig & !Torso, ...
* Let's me change the color of the thumbnails via LDraw color number or general color picker
* Does also a little bit of formatting as LDView does for it's Parts List
* Would not rely on existing image databases. It would use it's own renderer or an external viewer. Databases on Peeron or Bricklink do not have images of all part in all colors.

Anybody out there with the required skills and a bit of spare time left?

w.
LEGO ergo sum
Reply
Re: Offline Parts Catalogue
#4
Willy Tschager Wrote:Databases on Peeron or Bricklink do not have images of all part in all colors.
w.

Which is only because last time I tried to regenerate the entire library in all the LDConfig.ldr colours (which should be done at each Parts Update), we ran out of disk space on the server - and crashed the Parts Tracker.
Chris (LDraw Parts Library Admin)
Reply
Re: Offline Parts Catalogue
#5
Maybe I can be the one you are looking for if ldvlib.dll can save images.

I should be able to create whatever you need, if the data are in the library files.

If we are going to have a PDF file you do not need to have search capability in the application as you can search in the PDF file.

I can think of 4 pieces on one page on the left side and on the right side all necessary data are listed. Attached you find such a pdf as quick hack (delete the last 4 characters from the filename after saving to your hard disc).


Attached Files
.ini   PartCatalogue.pdf.ini (Size: 58.85 KB / Downloads: 0)
Reply
Re: Offline Parts Catalogue
#7
With currently some 5000 parts in the library you would get some 1200(!) pages by putting only 4 parts on every page. I think something like this:

http://www.holly-wood.it/tmp/Parts%20Catalog.pdf

(with in mind that some crazy head actually try to print the catalogue for a handy use) would do a better job.

w.
LEGO ergo sum
Reply
Re: Offline Parts Catalogue
#9
Ok, just a list of the parts like already in parts.lst, but with pictures - should not be that difficult.
My only concers are at present the pictures. I'll have to check how I have done in my OMRMaker.
But keep in mind, that you can not see much details of the parts if the parts much larger than an 1 x 1 Brick !

One more thought about your suggestion - There is no additional information like KEYWORDS or CATEGORY in your suggestion. I think that should be included, as it can be found by searching for a specific text!
Reply
Re: Offline Parts Catalogue
#6
I started working on a shell script to do this with LDView from the command line. Unfortunately, I ran into an LDView bug (LDView crashing when rendering many parts on the command line), so I need to fix that before I can continue with my script. Assuming I fix the crash, I should be able to produce a script. However, the script is a bash script, which will work great in Linux and on the Mac, but will require bash and associated helper commands to be installed in order to work in Windows. (Associated commands are things like sed and tr, plus basic stuff like mkdir and rm, which should be present in any bash for Windows.)
Reply
Re: Offline Parts Catalogue
#8
Well, it's not that I pretend compiling such a catalogue by myself on my win notebook. As long as I get a fine pdf (the way I want it ;-) for the AIOI I'm more than happy to delegate all the workload to linux or mac users.

w.
LEGO ergo sum
Reply
Re: Offline Parts Catalogue
#10
I got the crash bug fixed, but ran into another one (apparently related to SaveSnapshots with multiple input files). I still need to investigate that. I'm sending the parts to LDView 100 at a time to make it run faster, and for three or four of the batches (out of the 6000+ parts), LDView just stops for some reason part-way through.

I got Chris Dee to send me the command line options he's using for the ldraw.org part images, so the images I end up generating should match those, once I'm done.

One nice thing is that the Mac has print-to-PDF built in as a standard feature of its Print Dialog, so I don't have to worry about installing a converter. I just have to try to find a web browser that nicely paginates. (Last I checked, Firefox didn't; hopefully Safari or Chrome will.)
Reply
Re: Offline Parts Catalogue
#11
Well, I generated a list in HTML format for all the parts whose filename starts with 4. (This makes testing more managable.) I then printed that to a PDF. Unfortunately, none of the browsers I tried (Firefox, Chrome, Safari, and Opera on the Mac, IE 9 on Win 7) did a very good job with page breaks. The best was Firefox, and it's not exactly great. You can see the (6.4MB) PDF here:

http://www.halibut.com/~tcobbs/ldraw/pri...4Parts.pdf

Let me know what you think.

Note that my generated HTML includes a "page-break-inside: avoid;" CSS tag for <tr> elements, and Opera is supposed to support that CSS tag. However, either I did it wrong, or Opera's claimed support is bady broken, because it actually ended up looking a lot worse on Opera than on Firefox. (Firefox isn't supposed to support that particular CSS tag.) Also, Firefox was the only browser that included the header at the top of each page.
Reply
Re: Offline Parts Catalogue
#12
Why not just leave it html ? A collection of jpg's and html files is just as useable offline as a large (slow) pdf. Even simple search will work using the browsers ctrl+f or maybe some javascript.
Reply
Re: Offline Parts Catalogue
#13
That's a good point. I don't have a problem leaving it as HTML, but I feel it should be pointed out that the full list HTML page is brutal on web browsers, and the PDF version would likely in fact be faster. (I think Adobe Reader only loads the visible pages, not the whole document. Loading 6000+ images all at once in a web browser can in fact be slow.)

Right now, the HTML I generate is sorted based on the filename (because that was easiest), but I could see sorting based on the part description, and dividing it into a separate HTML page for each category, with a main page with links to each category. That would cut down on the size of any given page.
Reply
Re: Offline Parts Catalogue
#14
The huge amount of pictures might be a problem indeed, although some browsers are getting 'less good' at wasting resources. Smile

Adding the picture dimensions to the img tags (if not so already) might help. That way the browser can format the page without reading all the actual images, i could imagine some optimizations are based on that information.

Or make multiple html files, linked to by (cross) index page(s).
Reply
Re: Offline Parts Catalogue
#15
Well, it looks promising as a starting point. Personally I would prefer to see the pics aligned to the left - but this is taste. Did you succeed with the page-break in the meantime?

I'm not so sure about the html versus pdf. I guess a pdf is in this case just what people expect from this type of thing. On the other side I prefer a html if the page-break is not fixable.

w.
LEGO ergo sum
Reply
Re: Offline Parts Catalogue
#16
Just another thought.
I have seen html pages that are generated from xml files with xsl format rules. By doing this you can quickly change the sort order of things.
Maybe it's too slow on the other hand because it has to be one large file. IMHO.
Reply
Re: Offline Parts Catalogue
#17
The images are right justified because otherwise there is a huge gap between small parts and the other columns. Moving the images to be the last column would allow them to be left-justified.

I didn't have any luck on the page breaks, and unless Firefox adds support, I don't see that changing. (None of the other browsers repeated the table header at the top of each page.)
Reply
Re: Offline Parts Catalogue
#18
I also got LDView crashed twice on part no. 2700.dat if running in batch mode.
Maybe this is already fixed, but I like to mention it. I used Version 4.1 under windows xp.
Reply
Re: Offline Parts Catalogue
#21
The crash I fixed was related to ~Moved to parts, and 2700 isn't a ~Moved to. So, I don't think my fix will fix the crash you're seeing. I haven't personally seen a crash for that part, but I will test some more. What version of LDView are you using?
Reply
Re: Offline Parts Catalogue
#22
Code:
I used Version 4.1 under windows xp
Reply
Re: Offline Parts Catalogue
#24
Hopefully that means that I fixed the bug in my 4.2 tree, but I'll see if 2700 crashes for me when using LDView 4.1 from the command line.
Reply
Re: Offline Parts Catalogue
#19
Currently I am generating for each of the 6774 part a picture, sized 80 x 60. It is still not finished and I have currently already 29 Mb of filesize in the picture folder.
I think it will be in the end nearly 35 Mb only for the pictures.

Is it really a good idea to have all parts with pictures in one pdf file?

It is just ready: 40,3 MB (42.355.647 Bytes) disc space is lot more due to cluster size.
Reply
Re: Offline Parts Catalogue
#20
I'm using similar logic to what Chris Dee uses on LDraw.org to generate autocropped pictures with consistent zoom factor. I use 512x512 as the maximum image size, but position the camera at a set distance, so that most parts get cropped to be much smaller than 512x512. My end result is around 50MB.

Right now, I'm working on dividing the output up into a separate HTML page for each category. Having all 6000+ images in one page was causing problems in some web browsers.

Unless we can come up with a way to nicely paginate the results, combining everything into a single PDF isn't really useful. Having said that, Adobe Reader shouldn't have any problems viewing such a file, no matter how big. It doesn't load everything into memory up front as far as I know. In fact, I have an option in my script to generate all the images twice as big, then show them in the HTML page at 50% scale so that they will look nicer in the PDF. Since I'm not generating a PDF, I'm not using that option, although I suppose it would also produce really cool results on Apple devices with Retina displays.
Reply
Re: Offline Parts Catalogue
#23
Two days needed my computer to build all (pictures, html page, pdf file).

Visual Parts Catalogue (now hosted at Google Drive)

Please let me know what you think.
Reply
Re: Offline Parts Catalogue
#25
Do you mean that the computer itself spent 2 days rendering the content?

The one I'm working on takes my 4 year old Macbook about 15 minutes to generate all the images and HTML (using a bash script). The PDF output I got from printing from web browsers didn't look good; I didn't try importing into OpenOffice, though.

I have spent a fair amount of time on and off over a number of days working on the script, so if you did everything, including writing the tools to generate the output in two days, that's good.

The file looks really nice. It's paginated quite nicely, which is something I didn't get when trying to use web browsers.
Reply
Re: Offline Parts Catalogue
#26
No, not only rendering. That took approx. about 10 hours, but as I had several crashes (not only 2700.dat) and that caused by app to wait.
My system is about 7 years old (1.3 GHz - single core), so I expect that it should be done faster if running on an uptodate system.

I should have also mentioned that I reduzed the resolution of the pictures on PDF creation process because of saving filesize.

OpenOffice should also give good results with your html source as I think that the page brake in PDF export will be done only for full table row.

By the way, how should the command line looks like, if I like to have all pictures showing the parts in the same ratio (small picture for small parts - large picture for large parts) ?
Reply
Re: Offline Parts Catalogue
#27
I need to modify my script to output both categorized HTML and a full list HTML. (I modified it to categorize the parts so that the individual HTML files would be smaller, because the big one was crashing some browsers.) Once I do that, I'll give OpenOffice a try for the PDF generation.

For consistent scale parts, I'm using settings that Chris Dee and I together worked out for the parts tracker. (I did the initial work, and he tweaked it to make things work better.) The parts are first divided into three categories: baseplates, panels, and everything else.

Baseplates are straightforward: the first word of their name is "baseplate". (You have to parse "~Moved to" lines to find the final name, otherwise "~Moved to" baseplates won't get recognized as baseplates.) Baseplates get rendered at half the scale of everything else.

Panels are identified by a short list of filename patterns, and get rendered from the opposite side so that you can see their printing, which would otherwise be on the back.

For the command line, I use the following options for all three categories:
Code:
-SaveWidth=512 -SaveHeight=512 -SaveZoomToFit=0 -SaveAlpha=1 -AutoCrop=1 -FOV=0.1

For baseplates, I use the following:
Code:
-cg30,45,600000

For panels, which are recognized based on their filename with a regex of "^(4864|6268|4215|2362|4865|4345ap|4345bp)[^0-9].*", I use the following:
Code:
-cg-30,225,300000

For everything else, I use the following:
Code:
-cg30,45,300000

Note: the big numbers above (600000 and 300000) are from my memory. I tweaked the values that Chris sent me (400000 and 275000), so they might not be exactly correct.

Also note that a few parts (48x48 baseplate, really large train bases) get clipped by the above settings. There are few possible solutions to that:
  • Pull the camera back for everything to draw everything at a smaller scale.
  • Pull the camera back just for them to draw them at a smaller scale.
  • Pull the camera back, but increase the maximum image dimensions by a comparable amount.
  • Some combination of the above.
Reply
Re: Offline Parts Catalogue
#30
Thank you very much for your detailed information. I'll have to see how I can incorporate that.
I'll keep you updated.
Reply
Re: Offline Parts Catalogue
#31
I just checked my script, and the big numbers I use in the -cg option are 275000 and 550000, not 300000 and 600000.
Reply
Re: Offline Parts Catalogue
#28
Excellent work! Perhaps there could be two versions, one targeting file size (this one is great for that) and one with better image quality/lower compression?
Reply
Re: Offline Parts Catalogue
#29
I also like to add in the final version the category and the keywords, so you can search also for that strings. I think that I need then a smaller size for the letters.
I'll keep you updated.
Reply
Re: Offline Parts Catalogue
#32
Has nobody considered implementing this in LaTeX? I would think you could automate a lot of these tasks (after generating a bash script) and not have to worry about the intermediate rendering.
Reply
Re: Offline Parts Catalogue
#33
Have you ever tried to get LaTeX to properly process a long table with many pictures? I know it works in principle, but in my fairly extensive experience that relies on the two aspects of LaTeX that are least reliable.

Tim
Reply
Re: Offline Parts Catalogue
#34
I never learned LaTeX, so I went with what I knew (HTML).

As it turns out, OpenOffice and LibreOffice can both do a fairly good job of importing the huge HTML table and paginating the result, and both support PDF export. I have created two PDF documents (one standard, one with double-resolution images) and sent them to Willy, and he plans to make them available in the not-too-distant future (hopefully by the end of the year or early next year). For reference, the PDF with standard resolution images is approximately 34MB, and the one with double-resolution images is approximately 74MB. Both use lossless image compression inside the PDF, instead of JPEG.

FYI, the PDF documents are 821 pages long, so I doubt anyone will be printing them.
Reply
Re: Offline Parts Catalogue
#35
Did you also print the keywords to each part if they are present?
Reply
Re: Offline Parts Catalogue
#36
No, I didn't. They wouldn't really fit, given the size of the pictures I used. I'd like to generate a separate document that has those but no pictures that could be used as a cross-reference to the document with pictures. Another alternative would be to have the PDF document be in landscape, in which case a keywords column would probably fit.
Reply
Re: Offline Parts Catalogue
#41
I think you do not need to add a separate column for the keywords.
The picture is big enough that you can have two or three lines of text. IMHO

If I would search in that pdf for a special part, I just search for text.
Reply
Re: Offline Parts Catalogue
#42
I had in fact considered something like that, but it creates difficulty, because there's no obvious column to put the keywords into. Another alternative is to just make the text be multi-line, with prefixes, but that might greatly increase the page count, because there are a whole bunch of quite small parts that currently only take up the space of one to two lines of text. So, if I add keywords, the layout might look like the following:

Code:
_=_
Description: Minifig Head with SW Scout Trooper                    /0"0\
       File: 3626bpse.dat                                          | ' |
   Keywords: Star Wars, Episode VI, Empire, Speeder Bike, Endor    \___/

Note: I used the code tag above to line things up. The actual HTML I output would use HTML for the alignment.

The advantage of the above is that it would remove the need for the column headers at the top of each page. And, perhaps it would be easier to read.

Thoughts?
Reply
Re: Offline Parts Catalogue
#43
I like this multiline approach, it facilitates searching within the file and looks just nice and right to me.
But I would put the image in the left column.
Reply
Re: Offline Parts Catalogue
#44
The reason the image is on the right is because Willy (justifiably) complained about right-justified images when the image was on the left. And, since the images vary so greatly in size, they really need to be right-justified when on the left. Overall, I think having them left-justified on the right works better than right-justified on the left. Having them left-justified on the left just looks bad.

I will generate a file with the above modified formatting without keywords to see what it looks like. If it looks good, I'll add the necessary code to my script to include keywords when present (skipping that line for files with no keywords).
Reply
Re: Offline Parts Catalogue
#45
hmm, what about "horizontally centered within the leftmost column"? does that look better?
Reply
Re: Offline Parts Catalogue
#46
The images range in size from about 20 pixels wide all the way up to 512 pixels wide. If they are centered, the that decreases the size of the maximum possible space from 492 pixels down to 246 pixels (plus inter-column spacing), but it's still a very big gap. On the flip side, the new text will have a wide range of widths also, while my current middle column is the filename, which has a fairly narrow range of widths. So I may have to put the images on the left again (probably right-justified in their column).
Reply
Re: Offline Parts Catalogue
#50
as we have some fairly HUGE parts, it could maybe be an idea do restart a new table every, say, 100 parts, or when the first word of the title changes.
this way these large part exceptions won't force the whole table to have an unnecessarily wide picture column.
another idea could be to, if an image exceeds a certain pixel size, exceptionally scale it with a different factor.

(sorry, if you already have incorporated ideas like these, I had no time to check that)
Reply
Re: Offline Parts Catalogue
#51
I use a fixed maximum size, and most parts that are known to be too big (baseplates) get scaled differently than the rest (half scale). A few parts still get cropped by a little bit. Unfortunately, after I made my formatting changes, Libre/OpenOffice could no longer open the big file. They could happily open the smaller categorized files, but not the one file that contained all parts. I'm investigating to see if I can use a master document that contains all the categorized files. I think I can make that work, in which case there will be a separate table for each category.
Reply
Re: Offline Parts Catalogue
#52
I discovered that Dropbox allows you to publicly share specific files via a link that will work for anyone, including non Dropbox users, so here is a link to the 34MB PDF I produced:

https://dl.dropbox.com/u/77319025/LDrawO...atalog.pdf

The above PDF includes keywords, so is nicely searchable.

Let me know what you think.
Reply
Re: Offline Parts Catalogue
#53
Looks quite good, but still needs a little improvement.

Some text for the pictures is not on the same page than the picture.
If you can not solve this issue it might be a good idea to add horizontal lines after each part. So you can better identify the rows.
Reply
Re: Offline Parts Catalogue
#54
Looks great overall... imho, the words "Description", "File" and "Keywords" bring little and eat-up valuable space. What about using color/character coding instead (eg. light gray background for description, italic characters for keywords)?
Like Mike, I think that a thin line below each item would be great.

Otherwise...
- Image for parts 57909, 30163, 776p15, 2586ph1, 30016, 3049a, 3229ac01, 4180a , 3483 and 48169 are truncated
- Perhaps ~ parts should be removed? It seem that overall they are removed, but some crept in (seems this occurs when these parts have a category)
- Mursteen bricks look weird (missing slotm primitive?)
- Wrong decoration subfile for 4346p01, 80394?
- Sometimes the 1st character of keywords is missing (eg. 3837) though it's there in part file. Seems to happen when 1st keyword begins with letter 't'.
Reply
Re: Offline Parts Catalogue
#55
Yes, different coloring sounds good.
Reply
Re: Offline Parts Catalogue
#56
Would it be sensible to include a standard header on each page , to say what this is - "The Offline Illustrated LDraw Parts Catalog", and some copyright notice in a standard footer?
Chris (LDraw Parts Library Admin)
Reply
Re: Offline Parts Catalogue
#59
My plan (conceived after posting the link) was to add a cover page to the very beginning of the document that gives that kind of information, as well as naming the document, along with including the official LDraw.org logo. If you really think it's necessary to add a footer with copyright info to every page, I'm pretty sure I can do that fairly easily, but I'd prefer to have all that kind of information be confined to a cover page.
Reply
Re: Offline Parts Catalogue
#58
I checked my HTML, and the image for 57909 is fine there, so it appears to be due to an OpenOffice.org bug. I'm going to assume that the other truncated images are also OoO bugs. I guess we'll see when I do it again if the bug is repeatable, but there's not really anything I think I can do about it.

It seems to me that the ~ parts are necessary for people who want to be able to pose the composite part in a different way than the standard way. For example, if you want the handle on 73037 to be on the top instead of the bottom, you need the ~ parts.

The Mursten problem is my fault. I ran my script against a fresh complete.zip, but forgot to set the LDraw dir on the command line to use that directory to find its primitives, and I didn't have the latest update installed in my actual LDraw dir. That will be corrected the next time I run my script.

4346p01 and 80394 are both broken in the current latest official parts release. What you see in the catalog is what users see in models. I believe that there are corrected versions of both on the tracker.

I'll have to investigate to see if I can figure out why the first character of some keywords is missing. It's definitely a problem with my script, but I can't figure out what would cause it to do that, but only sometimes.
Reply
Re: Offline Parts Catalogue
#60
Quote:It seems to me that the ~ parts are necessary for people who want to be able to pose the composite part in a different way than the standard way. For example, if you want the handle on 73037 to be on the top instead of the bottom, you need the ~ parts.
Actually that's more a sorting issue, since you have ~ and _ parts appear grouped at the end of document. To me it seems that a ~xxx part having a yyy category appears with other untilded parts in category yyy while it should be in ~yyy section.
Reply
Re: Offline Parts Catalogue
#61
I'm not entirely sure I understand what you're saying. Could you give me an example?
Reply
Re: Offline Parts Catalogue
#62
- Parts 30188, 30189, 30189c01 are ~Bike xxxxx, but have a car category. Thus they are sorted with other "cars" in cars section, instead they should be in ~Car section with parts 30242, 30278...
- Part 5051, ~Boat Bow 12 x 12 x 5 & 1/3 Hull Inside has (wrongly) a boat category. It is sorted with other boat parts, while it should be in ~Boat section. Same thing for 2556, 2559, 6052 and a few other.
- Part 80298, _Minifig Shield Triangular with Black Falcon Pattern is in "minifig accessory" section, while it should be in a "_minifig accessory" section near the end of catalog.
Reply
Re: Offline Parts Catalogue
#63
I like to step in here.

We have decided to categorize the parts. Mainly on the base of the first word, or on special line CATEGORY. The prefixes ~ or _ are never ment to be in any case a category like the first word. They are just indicating other attibutes of the files. So please do not mix that!
Reply
Re: Offline Parts Catalogue
#64
I agree. I will remove the ~ and _ from the category names, so that those don't produce new categories, but instead push all parts with that prefix to the end of the category's list of parts.
Reply
Re: Offline Parts Catalogue
#57
Unfortunately, I have reached my limits on getting it to look nice. I may change "Description" to instead say "Name", which will decrease the amount of space taken up by that column, and I think I'll also make the font for those labels one size smaller. However, my original HTML has very carefully setup borders (which IMHO look quite nice), but unfortunately, OpenOffice ignores them. (MS Word shows too many borders, including a border between the label column and the other main text column, which looks bad also.)

If anyone else wants to take a stab at generating a better PDF file from my HTML originals, I'll see about getting the HTML posted. I have a few tweaks I want to make, but I'm not going to get rid of the labels, and I'm not going to be capable of adding lines.
Reply
Re: Offline Parts Catalogue
#47
Well, I modified my script to change the format to something similar to my above ASCII art (but with the image on the left of the text), but unfortunately, the updated table completely failed to import into Libre/OpenOffice with proper formatting. The only way I could find to nicely provide the above format was to use an embedded three row/two column table for each part's text data, and apparently that's not supported well by Libre/OpenOffice.

Word 2008 for Mac did a much better job importing the HTML, but had a different set of problems, so I'm going to investigate to see if I can fix those problems, and also investigate to see if I can come up with formatting that Libre/OpenOffice can handle, and still looks good.
Reply
Re: Offline Parts Catalogue
#48
After posting this, I realized that I had been stupid not to try rowspan=3 on the image column and using 3 separate rows in the main table to get the three rows of text, so I'll see if Libre/OpenOffice do a better job handling rowspan than they do handling tables embedded inside other table cells.
Reply
Re: Offline Parts Catalogue
#49
That should work. I have tried it this way.
Reply
Re: Offline Parts Catalogue
#37
Travis Cobbs Wrote:sent them to Willy, and he plans to make them available in the not-too-distant future (hopefully by the end of the year or early next year).

I would upload the high quality PDF immediately if only the download module of our CMS wouldn't be broken. Orion is working on it. As for the HTML version the Content Managers are discussing where it is best suited to store.

w.
LEGO ergo sum
Reply
Re: Offline Parts Catalogue
#38
Just to clarify, the files are 34.3MB for the standard one, and 73.6MB for the high-quality one, so I don't want to post them on the web server where I normally post links here. If anyone has a web server they would like to host the current files on, I'd be happy to send them links to the files.
Reply
Re: Offline Parts Catalogue
#39
Hi there i can host them aswell if need be
Reply
Re: Offline Parts Catalogue
#40
Send an email to LDView's email address, and I'll send you a link to the files.
Reply
Re: Offline Parts Catalogue
#65
I've been away for a while, so this is a bit late. I didn't see any mention here of the old "printable parts catalog". Maybe it's still useful?

http://www.nightsolo.net/lego/
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 2 Guest(s)
Forum Jump:


Users browsing this thread: 2 Guest(s)